On 15 December 2012 10:27, Janko Mivšek <[email protected]> wrote:
> Hi guys,
>
> 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?

>
> 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
>



-- 
Best regards,
Igor Stasenko.

Reply via email to