[SqueakDBX] About ports

[Juan]

Mariano folks


On Tue, Oct 6, 2009 at 7:00 AM, Mariano Martinez Peck
<marianopeck at gmail.com> wrote:
> Hi folks: There is some interest in porting SqueakDBX to different
> Smalltalks. Jan Vrany wants to port it to Smalltalk/X and Marcelo Cortez to
> Dolphin. So, the idea is to discuss here the necessary things I should
> modify so that this task is easier for you.
>
> I have been talking with Jan in ESUG and he found a couple of things I
> should do. In addition, I already did the stable release, so I can break
> whatever I want :)
>
> About the code, I will do these things:

>
> 1) Create the abstract class SqueakDBXSmalltalkDialect with all of the
> messages like self subclassResponsibility. This class will be in the core.

like template pattern?.

>
> 2) Create a package in my monticello repo called SqueakDBX-Dialect-Squeak
> and I will create there the class SqueakDBXSqueakDialect (subclass of
> SqueakDBXSmalltalkDialect ) . Now, for Squeak and Pharo users they will need
> not only the core, but also this package. If you want to put here packages
> like SqueakDBX-Dialect-SmalltalkX or SqueakDBX-Dialect-Dolphin, there is no
> problem. But I don't know if this is useful for you.
>
Dolphin don't support monticello, changeset is more appropiated. i think.

> 3) FFI calls. This is dialect dependent, but the current design is perfect
> for this :)
> I will keep the class abstract class OpenDBX  in the core and that will be
> the API. As you can see there are all the messages with a  self
> subclassResponsibility. I will then move my current subclasses of OpenDBX to
> the package SqueakDBX-Dialect-Squeak.
> Then, what you should to in your dialects is to create a subclass of it and
> use that. See the message OpenDBX class>>ffiImplementationForOS

ok.

>
> 4) WeakRegistry and GC: As you may know, we keep the connections in the
> WeakRegistry so that we can release the database connection when the GC
> collects a DBXConnection object.
> But this, again, is dialect dependent. So, the piece of code that was doing
> this, now it will delegate to the current SqueakDBXSmalltalkDialect
> subclass. In my case it will be SqueakDBXSqueakDialect but in your case it
> will be other.
>
Dolphin don't have weak collections.

> 5) Now, all the things that are dialect specific should be in
> SqueakDBXSmalltalkDialect and subclasses.
>
> 6) The core is thought in an ANSI Smalltalk. So, it will be difficult if for
> every message or class you don't have in your dialect I have to change
> something. That would be part of the port work :)   Anyway, we can discuss
> each of these situations and evaluate what to do.
>
>
> Now, about the procedure, as I talk with Marcelo, I think the best way to do
> this is to do something like TDD:
>
> - First you port the tests
> - You port the rests of the things until the tests are green :)
Yes agree ,then refactoring for Dialect's support/

in shot:
make it works.( green test)
refactoring ( plugability of dialects)
make run faster.

Best
Mdc


>
> What do you think about this?
>
> Best,
>
> Mariano
>
>
>
>
>
>
> _______________________________________________
> SqueakDBX mailing list
> SqueakDBX at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/squeakdbx
>
>