01-06-23 19.07, skrev [EMAIL PROTECTED] p�
[EMAIL PROTECTED] f�ljande:
> On Sat, Jun 23, 2001 at 03:20:43PM +0200, Artur Bergman wrote:
>> 01-06-22 02.35, skrev [EMAIL PROTECTED] p�
>> [EMAIL PROTECTED] f�ljande:
>>
>>> although this does not address the problem on the same level i would suggest
>>> using a proper object layer. i posted a very short plan for one some days
> ...
>>
>> I don't see how this is relevant.
> for most of the said problems you need extra information (to handle them
> well). so it is good to use these in a good way right from the start and
> not divide it into different parts.
this does not make sense
>>
>> A) I agree we need some kind of object layer, I think Rocco should tread
>> this path ahead of us
> the object layer he thought about seems to be different than what i want to
> do. at least according to the code pieces i received although they weren't
> many.
yes, and I believe there should be multiple object layers, Rocco should make
sure that is possible
>>
>> B) Must of us have homecooked object layers, we need to think hard how to
>> move forward
> well if you really have something similar to what i plan (check the mail)
> please share it with us then ...
> i don't have seen one, other people seem to want one too
>
>>
>> C) The poe kernel should have no concept of the object layer, multiple objet
>> layers must be able to exist. (Just like multiple kernels exist today)
> of course it is not about changing the kernel, such an layer sits on top
> of POE (and maybe other things like stem ?) did you read the short (sorry)
> description ??
and I never said that is like changing the kernel, I am saying that we need
propper support in the kernel so that any kind of object layer can exist
around it
>>
>> D) If the poe kernel doesn't manage to transparantly move messages across
>> kernel bounderies the object level will not help, if you don't want to
>> reimplment kernel level code in your object layer.
>
> not really. first of all it is intended to keep references in a better way,
> roughly said. it will use POE and poe sessions the same way it could use
> normal perl object refs. as events travel across these object associations
> it does not depend on poe kernel code at all. using IKC code for this would
> of course make sense though.
this too does not make sense
>>
>> Multiple layers GCing the same thing is an error prone approach.
>
> it is not. as i said above it sits on top of the perl kernel. and as layers
> are supposed to sit on top of each other, they use functionality of the lower
> layer. therefor they are not working on the same level. i did not say i'd
> write another perl kernel, did i ?
yes it is, you cannot GC kernel level information (sessions, events, alarms)
from the a top layer, if that is not what you mean sorry for
missunderstanding
> if you still doubt that there is a need, take a look at the differences
> between the design of a program (maybe in UML) and the resulting POE based
> code. the aim is to make this gap smaller and have as much of original design
> facts in programs as well. to realize this several things are needed,
> handling associations better being the most important one.
>
sorry I don't do UML :)
> torvald
>
I belive you are missunderstanding me.
What I said is that most of us have something like an object layer to make
coding sane that is used by us privatly.
Second I am not saying there is no need for an object layer, just that there
should be possibility of multiple object layers.
Artur
