Exploiting a new method trailer format(s)

Hello guys,

i am a dreamer. Did i say that?

Yesterday i started coding a new class, called a
SourceCodeManager

which will eventually replace the old stuff with SourceFileArray, RemoteString
manual parsing preambles , like (stephaneducasse 2/4/2006 20:32 ·
accessing · 2 implementors · in no change set · )
etc etc..

Initially, this facility will be responsible for retrieving a preamble
info + source by given sourcePointer.

But this is not all.
There is a basic class, BasicSourceCodeManager
which declares protocol, so you can make a subclass of it. Also, it
doesn't forcing you to use sourcePointer to be only integer values.

This means, that by fusing a new trailer formats + new, more flexible,
source code manager
we can make a great leap towards the future: use a remote storage for
our source code,
publicly available. Use it in a fashion, envisioned by Goran
(DeltaStreams) + techniques, used by git (add, commit, push ),
easily migrate the code, browse other's update streams , diff , merge etc etc..

These thoughts can't leave my mind once i started thinking how small
the efforts needed to make things rolling:
- JSON (already there http://www.squeaksource.com/JSON)
+ CouchDB (alredy there http://www.squeaksource.com/CouchDB, but have
to be revised... no idea why it using curl, while squeak has own means
to use HTTP stuff)
+ write CouchDBCodeManager (to be implemented)

you know what it means? It means that any code which you accepting in
browser, could be automatically posted on server.
And you can even configure image to not use local files at all!

CouchDB is extremely easy to use and fits for version-tracking,
because its inherently supports document versioning.

--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko wrote:
> There is a basic class, BasicSourceCodeManager
> which declares protocol, so you can make a subclass of it. Also, it
> doesn't forcing you to use sourcePointer to be only integer values.

Do us all a favor and do NOT name classes "Basic" or "Abstract" or
"Pure". Such names show utter lack of understanding of the problem
domain. Being abstract follows from the abstract concept represented
(Behavior, Number, Collection, String) and concrete entities have more
concrete names (Class, LargePositiveInteger, WeakSet, ByteString).

Cheers,
   - Andreas

2009/12/23 Andreas Raab <[hidden email]>:
okay, is SourceCodeManager name abstract enuf for you ? :)


> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

On 23.12.2009, at 15:13, Igor Stasenko wrote:
"Manager" is not really descriptive either ;)

I'm trying to remember where I read about how to name classes. Maybe it's one of Kent's Best Practice patterns.

- Bert -

I leaving you to name it properly ;)


2009/12/23 Bert Freudenberg <[hidden email]>:


--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko wrote:
> I leaving you to name it properly ;)

Actually SourceCodeManager is fine. It is only annoying when people
confuse the abstract and the concrete entities and "invent" such obscure
names as "AbstractString", "PureBehavior" or "BasicSourceCodeManager".
If SourceCodeManager is the abstract interface, then the concrete one
might be named StandardSourceFileManager (to access SourceFileArray) or
similar.

Cheers,
   - Andreas