Hi Esteban, I understand and support the cleanness focus, this is why Pharo actually seems very promising for the future. Just that cleaning should be gradual, in a sense that while introducing new you keep an old but clearly marked as obsolete for a, say, year or two. So that user base have a time to adapt to the new change. I think if you put the old FD in a ObsoleteFileDirectory package and load it by default for a year, then not anymore, this will certainly ease fears of some of us. Don't count me on this group, but I understand the guys, why don't like an approach you are going. Because it is user unfriendly even that a solution seems to be simple. Cleanness won't be hurt by that!
Best regards Janko Dne 15. 12. 2012 12:49, piše Esteban Lorenzano: > Let me explain this once again: we are not "backward compatibility > killer maniacs" :) > We prefer to keep backward compatibility whenever is possible, but we > don't put it as a top priority: if we find room to improve, we do it. > > but, since we take responsibility for all the packages loaded in what we > call "pharo", we rather prefer not to have duplicates, so we achieve one > of our goal (cleanness) while also focussing out effort. > > I'm sorry if that annoys some of you time to time, but that's the way to > improve: to change. > > Also... I think you are overreacting, in pharo 2.0 we just introduced > three big changes (visible to users): FS, SystemAnnouncer (who has, btw, > same API than old SystemChangeNotifier) and Nautilus... that's all. All > the other is infrastructure and shouldn't be a problem for anyone. > > Esteban > > On Dec 15, 2012, at 12:40 PM, Esteban Lorenzano <[email protected] > <mailto:[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... >> >> Esteban >> >> On Dec 15, 2012, at 12:31 PM, Janko Mivšek <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Dne 15. 12. 2012 12:12, piše Igor Stasenko: >>>> On 15 December 2012 10:27, Janko Mivšek <[email protected] >>>> <mailto:[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] <mailto:[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 <http://www.aidaweb.si/> >>>>> >>>> >>>> >>>> >>> >>> -- >>> Janko Mivšek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si <http://www.aidaweb.si/> >>> >> > -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
