On 13 December 2012 03:59, Chris Muller <asqueaker at gmail.com> wrote:
>>>  I have no interest in chopping on the great work being done by
>>> you and my other friends in Pharo, but that doesn't mean it is
>>> feasible for me to use it in my business.  While someone in the Pharo
>>> community said FileSystem over FileDirectory is "huge", I see it as an
>>> incremental API change, and close to being a matter of preference.
>>>
>> incremental?
>> do you think you can implement a memory-based and/or git-based filesystem or
>> 'remotely connected database-based file system'
>> by just doing incremental changes to FileDirectory?
>> good luck with such 'increments' :)
>
> 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).

So, i really doubt that you end up with 'little disruption to API'. It
will be substantial.

> Colin made a gorgeous domain model of an abstract FileSystem, no doubt
> about it.  If we switch to it in Squeak I'm sure I will be happy once
> the conversion is done.  I just think its worth asking, though,
> whether a "core" system should provide that rich a model
> out-of-the-box or instead just a bland, one-layer-above-the-primitives
> lightweight model ready to be easily wrapped by the user's _own_ rich
> model of a FileSystem.  Is the core system suitable for tiny embedded
> programs and will they want a rich model or a basic one?  Maybe Spoon
> will allow us to have our cake and eat it too..?
>

To me, design comes first. ALWAYS.
All of the rest is secondary. FileSystem establishing a clear
separation between conceptual model
and implementation detail.
The value of such improvement is hard to underestimate: users can
learn fast & grasp well
how to use it (and even understand better how file systems work).
Moreover, it makes FileSystem nicely portable among dialects.. So, in
future, if you would like to port your application to another dialect,
you'll have to port FileSystem backend, instead of walking over your
whole application and do patches all over the place..
Because once you have sound API, an effort to port application
gravitates down to zero.
Also, porting, in broad sense can mean 'porting from version X to
version Y' (speaking about 'backwards compatimilimulability).

API establishing a set of rules in a domain & models. The point is
that domain does not changes that often, comparing to implementation.
That means , if you have a good design, you can be assured that it
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).
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
language 'as is', but always come with API.
Because if you don't have rules, then you have very poor
maintainability inside of system, as well as forcing users to reinvent
their own wheel over and over again.. And next thing, if you would
want one day to change primitives or change VM.. you will immediately
hit the wall, with bloody 'backwards compatibility' sign on it.
Because you will discover, that every single application implements
own abstraction layer(s) (or even worse, use low-level functionality
directly) on top of what you provided.

So, to me, your statement looks contradictory:
from one side, you are seriously concerned about backwards compatibility,
but from another one, you trying to ignore/discard the facts that you
cannot have good
backwards compatibility without having a design and API in a first place.

-- 
Best regards,
Igor Stasenko.