Re: [Pharo-project] [squeak-dev] FileSystem (was: About (backwards) Compatibility)
Yes, of course those capabilities could be added simply with factoring work and little disruption to the API. That's the promise object technology, encapsulation.
The main problem with FileDirectory that there's no API. I can hardly call a single class as API... as to me, it is clear that file system domain is a bit more complex and in order to reflect it properly in a language you will need more that a single role (FileDirectory).
FileDirectory is actually made up of 10 classes providing a rich but utilitarian API for traversal, navigation, stream creation, copying and renaming, filename parsing utilities. Platform-specific implementations all share the same API, including one for remote FTP access. For you to say "no API" is silly.
So, i really doubt that you end up with 'little disruption to API'. It will be substantial.
To me, design comes first. ALWAYS. All of the rest is secondary.
Design should be a means to some end, not an end in itself. You can design for 20 years but if real-world results are never harvested then it was only ever just playing around with a cool toy. My goal is to get as far along my software journey as my limited lifespan will allow..
FileSystem establishing a clear separation between conceptual model ... snip ... won't require serious changes and will serve you much much longer without need to change anything in userland code. (Take a Collection protocols for example).
.. and so when I become faced with having to make "serious changes" in my "userland code," (e.g., a complex ODBMS system) just to hold position along my journey; naturally I'm resistant. You can try to justify it with design theory but, at the end of the day, the two frameworks do basically the same thing, converting to it is mostly pure cost.
Also, once you have such set of rules, it is much easier for people to maintain implementation code, as well as adding extra functionality if needed.
Clearly, VM interfaces (such as primitives) should be not exposed to ...
Igor, a very good explanation for our individual views here is that your journey is building a great new Smalltalk, mine is something else. Cheers, Chris
On 13/12/12 10:24 PM, Chris Muller wrote:
Igor, a very good explanation for our individual views here is that your journey is building a great new Smalltalk, mine is something else.
I don't see that as a good explanation. I see different paths to similar goals. The Igor/Pharo path is to first improve the Smalltalk, and from that platform, scale even greater heights than could have been imagined from the "random walk" along "safe" path.
On 14 December 2012 05:13, Yanni Chiu <yanni@rogers.com> wrote:
On 13/12/12 10:24 PM, Chris Muller wrote:
Igor, a very good explanation for our individual views here is that your journey is building a great new Smalltalk, mine is something else.
I don't see that as a good explanation. I see different paths to similar goals. The Igor/Pharo path is to first improve the Smalltalk, and from that platform, scale even greater heights than could have been imagined from the "random walk" along "safe" path.
right. the same as Marcus says about "base camp": You can climb mountain each time from the very bottom of it, or you can prepare first, and build a base camp which will make your expedition less difficult. -- Best regards, Igor Stasenko.
participants (3)
-
Chris Muller -
Igor Stasenko -
Yanni Chiu