Re: Found some incompatibilities

--- messju mohr <[email protected]> wrote:
> I like that approach. We should return boolean false if the fopen
> fails, though (as the native file_get_contents() does).
> 
> There are just two things that make me feel uncomfortable:
> 
> #1 _read_file() locks the file with LOCK_SH before reading. I don't
> know if there are any negative side-effects if we replace this by
> file_get_contents (which doesn't lock AFAIK).
> 
> I don't know of any dependency inside smarty on this shared lock: It
> doesn't work Windows anyway and _write_file() works with writing to a
> temp-file and an "transactional" rename() command so it doesn't need
> a lock. But I'm not 100% sure if the lock is beneficial somewhere.

Read locks are the worst. I know of no issues surrounding the lack of
this feature in terms of Smarty. If someone would REALLY need a read
lock I'd suggest using an acid db as a resource.

> #2 we should also change fread() in Config_File.class.php to
> file_get_contents() if we go for this approach. Config_File is known
> to be usable outside of Smarty. If smarty defines it's own
> file_get_contents() for older php-versions, than Config_File would
> break without Smarty and older php versions.

This is one of the reason's I suggested a "compatablility" layer file.
We could put the platform targetted code into a single file and include
it where necessary. One alternative is to use something like the
following pseudo in the config class:

if !function_defined( file_get_contents ) // older PHP version AND
smarty not loaded
   ... legacy fread code
else
   file_get_contents...

In other words, the new behaviour only gets executed on older PHP's and
also when the class is loaded without Smarty also being loaded (since
Smarty would otherwise define that function).

I'm still against having ANY resource acquisition in the config
class--I maintain that it would be beneficial to separate the tasks of
reading/writing and parsing which are presently combined in the config
classes. In my mind, the config class should be dependant on the
already established core features for disk access, etc. As it is, the
config class "redoes" a few of the things that Smarty has hammered out
just so that it can also stand on its own.

> If these 2 drawbacks are acceptable by Smarty's userbase I'm for
> providing a function like the above in Smarty.class.php and let
> Smarty move to 4.3.0's file_get_contents().

xo boots

__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

-- 
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php