inherited lips

[Mildred Ki'Lya]

Hi,

On 09/16/2009 08:50 AM, Damien Bouvarel wrote:
> Hello,
> I started to convert the opengl binding for new syntax, i have a lip
> problem already pointed by Mildred:
> how to import a lip from a lip?

Now, it's not possible :)

> The opengl lib has a unix/ windows/ os layer, so it need a lip
> configuration, as the lib is not standard, it can't be in lib_os/
> My proposal may be the same as Mildred solution :-)

Well, it's not really the same.
The idea I had did not included to inherit from the lip we need.

You might say I preferred composition instead of inheritance. But that's
a semantic problem, and does not change the core of the idea I think.

But I don't see why inheriting from lip libraries. I don't understand
it's advantages. Put it that way, I don't see how an OpenGL application
is a kind of OpenGL library (inheritance). And this would also require
to change how inheritance is managed in lip currently (you can't call
parent.slot).

> The inherited lips are not STRING but LIP type, all the "imported"
> lips are inherited:
>
>  - parent_lip:LIP := LIP; // ??? LIP is the lisaac make.lip object.
>
>  - parent_opengl:LIP := LIP.create "<opengl lip path>";
>
> So the public slots are inherited, we have the explicit call:
> parent_opengl.no_shader; or no_shader; or -no_shader on command-line.
> The 'make' slot is interpreted by compiler at 'LIP.create' call, this
> make slot can be used to set up the path.
> So when we inherit from opengl lip, the opengl path is set, if opengl
> lip inherit from math lib, the math path is also set.
>
> A dynamic lip load could look like this:
>
> + lib:LIP;
> + my_path:STRING;
> ...
> lib := LIP.create my_path; // make is called
> lib.toto;
>
> All this may have already been thought, comments?
> Damien

The idea of being able to call library slots from the command line is I
think a good idea.

Now, what I see coming in the future is instead of having the Section
Public and Section Private in the lip like we have currently, we could
have a Section Public, a Section Private and a Section Options (command
line). This would make sense since we would have different lip objects
interacting.

Now, being able to call options for any lip is interesting :)

Mildred


-- 
Mildred Ki'Lya
╭───────── ｍｉｌｄｒｅｄ５９３＠ｏｎｌｉｎｅ．ｆｒ ──────────
│ Jabber, GoogleTalk: <mildred at jabber.fr>
│ Website: <http://ki.lya.online.fr>           GPG ID: 9A7D 2E2B
│ Fingerprint: 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/lisaac-devel/attachments/20090918/36571bcb/attachment.pgp>