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...
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 >
