I'm tired of talking about this but I just can't let this go..  I
don't know if its just romantic, starry-eyed mountain climbers or
intentional false-propaganda but...  confusion reigns here!  :)  This
example is bunk.

Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002
which, for whatever reason, is admittedly not great code but that's
not the point -- Sean is trying to use this example to demonstrate how
using FileSystem will let you "scale new heights" over FileDirectory.
The real equivalent to what Sean wrote is:

"FileDirectory"
 localFileName: aString
        | file |        
        super localFileName: aString.
        file := FileDirectory directoryEntryFor: aString.       
        file exists ifFalse: [ ^ self ].
        self modifiedAt: file entry modificationTime.

"FileSystem"
 localFileName: aString
        | file |        
        super localFileName: aString.
        file := aString asFileName.     
        file exists ifFalse: [ ^ self ].
        self modifiedAt: file entry modificationTime.

Ahhhh, I've broken all my systems but look how I'm scaling new heights
with FileSystem!  (not!)



On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris
<[email protected]> wrote:
> Chris Muller-4 wrote
>> While someone in the Pharo
>> community said FileSystem over FileDirectory is "huge", I see it as an
>> incremental API change
>
> Can you still say that after reading
> http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?!
>
> FileSystem has hugely decremented the number of times I've wanted to throw
> my computer at a wall ;) FileDirectory occurred to me like graffiti painted
> on a great work of art.
>
> Multiply the above by every dark corner of the system and you have the
> barrier to the next stage of evolution. For myself, every time I've embarked
> on a bold new idea for our IDE, after getting bogged down in a mess of
> objects - like FileDirectory et al, or Paragraph and friends, or Morphic
> layout objects, and on and on - I reached a point where I was not willing to
> put in the tremendous effort required to understand the system (if even
> possible). And because few of the design decisions are documented, I didn't
> know how to clean things without breaking them. So, I gave up and just went
> back to the standard tools.
>
> I hate to keep repeating myself, but the Pharo manifesto is very clear, and
> makes these types of arguments moot:
> - Better for the better
> - Beauty to learn from
> - Not backward compatible
> - Clean, lean and fast
>
> Cheers,
> Sean
>
>
>
> --
> View this message in context: 
> http://forum.world.st/About-backwards-Compatibility-tp4658784p4659133.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

Reply via email to