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

Reply via email to