Hi guys, Is there any technical reason that the old FileDirectory stuff doesn't stay and work in parallel to a new FileSystem? Maybe in some package marked obsolete. Both use the same plugin and the same primitives, so where is the problem?
I also think that for a professionally viable product a clear migration path should be provided. Progress yes, but user base must have a guidance how to slowly migrate to the new functionality. If possible with some automated procedure to migrate our code. In case of FileSystem/FileDirectory, this is certainly quite a big change and will break a lot of code. Be sure therefore that you guide us as much as possible, otherwise there is a danger to loose a lot of user base behind. Best regards Janko Dne 15. 12. 2012 08:55, piše Stéphane Ducasse: > Chris > > Could you give us a break pleaseeeeeee? > We are spending all our energy to build a better system that other people can > use to make a living. > May be we should just create a system for having fun in our teams? Because at > the end of the day > we just need to produce ideas and some prototypes (not even build them as > researchers). > > I really think that there are still plenty of places where the system is not > good. If you disagree then you may want to > spend more time trying to extend it and build something real with it. (Here > this is the place where you should react and prove > to the world that you are a cool entrepreneur) ;D > > Now nobody force you to: > - be in this mailing-list (you are welcome here but can we avoid this > kind of endless useless discussions) or > phrase your points with code snippet that can help the system. > > - use pharo in fact you are not using it so you are living in an happy > world. So this is perfect. > > Did you read the Pharo motto? > > Stef > > > On Dec 14, 2012, at 5:55 PM, Chris Muller wrote: > >> 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 -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
