2009/12/15 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Sun, Dec 13, 2009 at 5:01 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
>>
>> Ken G. Brown wrote:
>>>
>>> At 12:14 AM +0200 12/14/09, Igor Stasenko apparently wrote:
>>> Not sure how this relates exactly but there has been quite a bit of work
>>> in the past re: Virtual Image 4.0 format.
>>> See:
>>> New Compiled Method Format
>>> <http://wiki.squeak.org/squeak/750>
>>>
>>> and:
>>> VI4 project
>>> <http://wiki.squeak.org/squeak/2119>
>>
>> It doesn't relate. There may be some inspiration for how to deal with
>> source pointers but to be honest, I find Igors approach vastly more useful
>> since it doesn't immediately add a megabyte or more to the image size (which
>> would happen if you go to an explicit source pointer representation) but
>> rather makes the encoding explicitly accessible.
>>
>> Go Igor!
>>
>> Cheers,
>>  - Andreas
>>
>> PS. The only person who I'd like to explicitly comment (even if only to
>> say "that's fine") is Eliot, since he might have some additional thoughts
>> about some of this stuff which relate to Cog.
>
> and I've been explicit on my blog that I don't think that the current
> compiled method format is bad.  I still think its compactness makes sense.
>  providing some abstraction for accessing trailers is a good thing as long
> as it doesn't add significant overhead, and Igor's approach respects that
> constraint nicely.
> <rant>I've been reading Codes at Work by Peter Seibel, and it's a quite
> brilliant book.  A couple of people in the book crtiticise the OO crowd for
> unnecessary abstraction.  KISS is really important, as in a networked world
> is compactness.  I think it is wise to avoid unnecessary decomposition
> (heavy emphasis on unnecessary here; if it is necessary then by all means
> decompose).   Arguably unnecessary decomposition are the fragments of
> SystemDictionary that have gone into SystemNavigation, SmalltalkImage et al
> (I like SystemNavigation, but SmalltalkImage seems pointless).  Much better
> to have a well thought-out distinction such as development vs deployment
> than an abstraction of a function into a class.  Related functions belong
> together in a single class. One would be insane to break out the arithmetic
> functions on Point (+,-,<<, >= et al) into a separate ArithmeticPoint from
> graphical operations such as e.g. isInRectangle:.  So for me breaking out
> the source pointer, having a separate byte array for bytecodes etc is all
> quiche.  Keep them compact.  Likewise, SourceFilesArray and SmalltalkImage
> are incoherent fragments.  Why not have a SystemFileManager that provides an
> interface to the sources files and the code to deal with renaming images
> etc?</rant>
>

Oh yeah.. SourceFilesArray. A quite representative illustration of
lack of abstraction.

I would call it at SourceCodeProvider and give a protocol:
#sourceCodeAt: sourcePointer
and
#methodStampAt: sourcePointer
and no, no more RemoteString crap.

Also, i tried to offer something to those who want to store sources
differently than system's default.
This is the reason why i added encoding of an arbitrary string identifier.
So, the scheme could be like: First, request comes to a class, where
the method installed, then class may either
answer the source code, or pass request further.
At the end of the day, you could use UUIDs for each method, and store
source code in some database.
Then provide a layer which talks with database for retrieving source
code. Since UUIDs do not need to be changed (in contrast to
sourcePointer, which needs to be changed if you compress the .changes
or .sources files), you can assign it once and keep forever.

The class+selector case is added to support metaprogramming. When you
having an anonymous class (or something which behaves like class), it
is pointless to log the source code in .changes when compiling the
methods, but still you could be able to store it somewhere, so user,
while debugging will see original source, instead of decompiled one.

>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.