On 12/15/12, Esteban Lorenzano <[email protected]> wrote: > Janko, > that's already done (since ever), and FD is provided in two different ways: > in the graveyard is the old FD package (loadable into pharo 2.0) > http://smalltalkhub.com/#!/~Pharo/Graveyard20 , and also Camillo made a FD > wrapper to FS...
Excellent, where is this FD wrapper to FS of Camillo available? --Hannes > Esteban > > On Dec 15, 2012, at 12:31 PM, Janko Mivšek <[email protected]> wrote: > >> Dne 15. 12. 2012 12:12, piše Igor Stasenko: >>> On 15 December 2012 10:27, Janko Mivšek <[email protected]> wrote: >> >>>> 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? >> >>> Yes, there's one big reason: maintainability. And manpower. >>> Who would like to maintain FD? Any takers? >> >> Gain with a (in this case very small) bit of manpower to ease upgrade to >> new FS by providing existing FD for a while outweighs the loss by not >> doing that. As a professional organization providing a professional >> product Pharo should think rather that way. >> >> Janko >> >>> >>>> >>>> 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. >>>> >>> But there is a well-written documentation of FS. >>> I wonder, if there's any documentation for FileDirectory ever existed. >>> >>>> 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 >>>> >>> >>> >>> >> >> -- >> Janko Mivšek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> > >
