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 <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> 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 <janko.mivsek@eranova.si <mailto:janko.mivsek@eranova.si>> wrote:
Dne 15. 12. 2012 12:12, piše Igor Stasenko:
On 15 December 2012 10:27, Janko Mivšek <janko.mivsek@eranova.si <mailto:janko.mivsek@eranova.si>> 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 <sean@clipperadams.com <mailto:sean@clipperadams.com>> 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