I've been thinking about your proposal and until now it seems to me quite sound. I particulary agree with you on separate being an attribute of a class and not of an object. I still haven't fully understood the rationale behind the rules dealing with reference objects which are usually the far majority of Eiffel objects. The imported objects looks like proxies, don't they?
Meanwhile I may import into git the toy ideas I has about SEPARATE being a class....
hui, you actually are thinking about implemented SCOOP. Cool and scary. (In daily life, I work on a Multi-core OS for automotive industry atm, but this is somehow another level ;-)
I think the object passing stuff is fine.
Actually, passing big structures by value is very expensive. We should try to generate some warning if the structure is big.
What does the first item in the definition exactly mean? I do not understand the sentence.
In the conformance rules, I suggest to exchange "a ts: TS" by "an instance of class TS" and also "a class T cannot" by "a (non-separate) class T cannot" (or is there a reason why a separate class cannot have any descendants?
And the last question for today: How is the mapping of (separate) classes and their objects to actual processors (threads) defined?
Raphael, thanks for your remarks. Feel free to update the wiki :-)
About the first sentence: "A class may be either expanded or separate, but not both." What don't you undertsand?
Yes, passing heavy structure is expensive. But where is the limit? Passing a "simple" STRING may be expensive if the string is big...
The mapping of processors is not yet defined. SCOOP, in theory, allows processors to be any kind of linear-running entity: either "heavy-weight" processes, "light-weight" threads, or something else entirely like processes running on another machine... Furthermore many processors may share the same entity.
Paolo, no, reference objects cannot be passed as proxies, it would potentially create deadlocks. I invite you to read the papers I cite in the wiki, they are quite instructive.
Mh, I actually meant the first point in the definition ("a reference or expanded object that belongs to the target’s pr...") but I just did not read the "lead" sentence "an imported object (from an original object) is".
Adding a warning for "big" structures is not simple. I already tried to fix an idea of the limit, but did not succeed. So I wrote the comment without a solution ;-) I even thought of suggesting the warning for all references classes. But this seems too restrictive. But... We need some method to specify the processor anyhow, so why not extend this with a list of all classes which are imported silently?
About the processors: I read the theory (a few years ago). I was asking for a practical idea for liberty. - Do you have one already?
I like your idea for "silent classes" list configuration. It has the benefit of being transparent. I don't like hard-coded values :-)
Although I'd link that list at least to the library configuration, not to some processor (although maybe the processor mapping could override it).
As for the processors mapping, I don't have any preconceived idea yet, although I think it will be some kind of language looking like Eiffel, as I like to do in ESE (the alternative being XML).
We'll come to that in its own time, let's bootstrap first ;-)
"We'll come to that in its own time, let's bootstrap first ;-)" - yes, that's good. And actually what I meant by saying talking about SCOOP now feels "scary".
I've been thinking about your proposal and until now it seems to me quite sound. I particulary agree with you on separate being an attribute of a class and not of an object.
ReplyDeleteI still haven't fully understood the rationale behind the rules dealing with reference objects which are usually the far majority of Eiffel objects.
The imported objects looks like proxies, don't they?
Meanwhile I may import into git the toy ideas I has about SEPARATE being a class....
hui, you actually are thinking about implemented SCOOP. Cool and scary. (In daily life, I work on a Multi-core OS for automotive industry atm, but this is somehow another level ;-)
ReplyDeleteI think the object passing stuff is fine.
Actually, passing big structures by value is very expensive. We should try to generate some warning if the structure is big.
What does the first item in the definition exactly mean? I do not understand the sentence.
In the conformance rules, I suggest to exchange "a ts: TS" by "an instance of class TS" and also "a class T cannot" by "a (non-separate) class T cannot" (or is there a reason why a separate class cannot have any descendants?
And the last question for today: How is the mapping of (separate) classes and their objects to actual processors (threads) defined?
Raphael, thanks for your remarks. Feel free to update the wiki :-)
ReplyDeleteAbout the first sentence: "A class may be either expanded or separate, but not both."
What don't you undertsand?
Yes, passing heavy structure is expensive. But where is the limit? Passing a "simple" STRING may be expensive if the string is big...
The mapping of processors is not yet defined. SCOOP, in theory, allows processors to be any kind of linear-running entity: either "heavy-weight" processes, "light-weight" threads, or something else entirely like processes running on another machine... Furthermore many processors may share the same entity.
Paolo, no, reference objects cannot be passed as proxies, it would potentially create deadlocks. I invite you to read the papers I cite in the wiki, they are quite instructive.
Mh, I actually meant the first point in the definition ("a reference or expanded object that belongs to the target’s pr...") but I just did not read the "lead" sentence "an imported object (from an original object) is".
ReplyDeleteAdding a warning for "big" structures is not simple. I already tried to fix an idea of the limit, but did not succeed. So I wrote the comment without a solution ;-) I even thought of suggesting the warning for all references classes. But this seems too restrictive. But... We need some method to specify the processor anyhow, so why not extend this with a list of all classes which are imported silently?
About the processors: I read the theory (a few years ago). I was asking for a practical idea for liberty. - Do you have one already?
I like your idea for "silent classes" list configuration. It has the benefit of being transparent. I don't like hard-coded values :-)
ReplyDeleteAlthough I'd link that list at least to the library configuration, not to some processor (although maybe the processor mapping could override it).
As for the processors mapping, I don't have any preconceived idea yet, although I think it will be some kind of language looking like Eiffel, as I like to do in ESE (the alternative being XML).
We'll come to that in its own time, let's bootstrap first ;-)
"We'll come to that in its own time, let's bootstrap first ;-)" - yes, that's good. And actually what I meant by saying talking about SCOOP now feels "scary".
ReplyDelete