New restriction in idl ??
amit...@my-deja.com
I am trying to compile my idl on VisiBroker 4.0
Idl uses same name for module as well as for the interface.
I have compiled it successfully in VisiBroker3.4, but when I try to
compile with 4.0, I get following error -
----------------------------------------------------------------
LTLoadBalancer.idl: 24:cannot use name LTLoadBalancer to define objects
within s
imilarly-named container ::LTLoadBalancer
1 error
-----------------------------------------------------------------
idl -
[.skip..]
module LTLoadBalancer{
interface LTLoadBalancer{ <<<< Line 24
[.skip..]
------------------------------------------------------------------
Can we not use same name for the module and the interface ?
Is it a new restriction ?
Thanks and regards,
Amit
Sent via Deja.com http://www.deja.com/
Before you buy.
Duncan Grisby
>LTLoadBalancer.idl: 24:cannot use name LTLoadBalancer to define objects
>within s
>imilarly-named container ::LTLoadBalancer
>1 error
>Can we not use same name for the module and the interface ?
>Is it a new restriction ?
Section 3.15.2 of the 2.3 spec says
"The name of an interface, value type, struct, union, exception or a
module may not be redefined within the immediate scope of the
interface, value type, struct, union, exception, or the module."
That section has change bars next to it, so I think it's new in the
2.3 spec.
Note that collision of identifiers ignores case, so the following is
illegal:
struct S {
string s;
};
HTH,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
Gerald Brose
>
> In article <863uar$nie$1...@nnrp1.deja.com>, <amit...@my-deja.com> wrote:
>
> >LTLoadBalancer.idl: 24:cannot use name LTLoadBalancer to define objects
> >within s
> >imilarly-named container ::LTLoadBalancer
> >1 error
>
> >Can we not use same name for the module and the interface ?
> >Is it a new restriction ?
>
> Section 3.15.2 of the 2.3 spec says
>
> "The name of an interface, value type, struct, union, exception or a
> module may not be redefined within the immediate scope of the
> interface, value type, struct, union, exception, or the module."
>
> That section has change bars next to it, so I think it's new in the
> 2.3 spec.
That section continues in paragraph 4:
"An identifier can only be defined once in a scope. However,
identifiers can be redefined in nested scopes. ..."
That's what is happening here, ::LTLoadBalancer::LTLoadBalancer is
not a redefinition of ::LTLoadBalancer within the immediate scope
but in a nested scope, so rejecting the definition cannot be
justified with this paragraph in the specification.
Regards, Gerald Brose.
--
Gerald Brose, Mail: br...@inf.fu-berlin.de
FU Berlin (for PGP key see:) http://www.inf.fu-berlin.de/~brose
Institut f. Informatik Ph-one: (++49-30) 838-75112
Berlin, Germany Ph-ax: (++49-30) 838-75109
Michi Henning
> That section continues in paragraph 4:
>
> "An identifier can only be defined once in a scope. However,
> identifiers can be redefined in nested scopes. ..."
>
> That's what is happening here, ::LTLoadBalancer::LTLoadBalancer is
> not a redefinition of ::LTLoadBalancer within the immediate scope
> but in a nested scope, so rejecting the definition cannot be
> justified with this paragraph in the specification.
Hmmm... The paragraph you mention is followed by:
The name of an interface, value type, struct, union, exception or
a module may not be redefined within the immediate scope of
the interface, value type, struct, union, exception, or the module.
For example:
module M {
typedef short M; // Error: M is the name of the module
// in the scope of which the typedef is.
interface I {
void i (in short j); // Error: i clashes with interface name I
};
};
How would you change it to express the intent?
Cheers,
Michi.
--
Michi Henning +61 7 3891 5744
Object Oriented Concepts +61 4 1118 2700 (mobile)
Suite 4, 904 Stanley St +61 7 3891 5009 (fax)
East Brisbane 4169 mi...@ooc.com.au
AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html
Gerald Brose
>
> On Wed, 19 Jan 2000, Gerald Brose wrote:
>
> > That section continues in paragraph 4:
> >
> > "An identifier can only be defined once in a scope. However,
> > identifiers can be redefined in nested scopes. ..."
> >
> > That's what is happening here, ::LTLoadBalancer::LTLoadBalancer is
> > not a redefinition of ::LTLoadBalancer within the immediate scope
> > but in a nested scope, so rejecting the definition cannot be
> > justified with this paragraph in the specification.
>
> Hmmm... The paragraph you mention is followed by:
>
> The name of an interface, value type, struct, union, exception or
> a module may not be redefined within the immediate scope of
> the interface, value type, struct, union, exception, or the module.
> For example:
>
> module M {
> typedef short M; // Error: M is the name of the module
> // in the scope of which the typedef is.
> interface I {
> void i (in short j); // Error: i clashes with interface name I
> };
> };
>
> How would you change it to express the intent?
Caught me, I'll accept it ;-). Obviously, it helps to read on.
While we are at it, what's the reason this clause was introduced
in the first place? Because some C/C++ compilers cannot handle it?
Thanks, Gerald.
Michi Henning
> > How would you change it to express the intent?
>
> Caught me, I'll accept it ;-). Obviously, it helps to read on.
>
> While we are at it, what's the reason this clause was introduced
> in the first place? Because some C/C++ compilers cannot handle it?
See my other posting on the topic. It's not *some* C++ compilers, it's *all*
of them. That's because most things are mapped to classes, but a class can't
contain a data member or member function with the same name as the class,
since that name is reserved for the constructor. The Java union mapping gets
bitten by this too, I think.
Gerald Brose
Michi Henning wrote:
>
> On Wed, 19 Jan 2000, Gerald Brose wrote:
>
> > > How would you change it to express the intent?
> >
> > Caught me, I'll accept it ;-). Obviously, it helps to read on.
> >
> > While we are at it, what's the reason this clause was introduced
> > in the first place? Because some C/C++ compilers cannot handle it?
>
> See my other posting on the topic. It's not *some* C++ compilers, it's *all*
> of them.
Missed your other posting here, so thanks for the information.
> That's because most things are mapped to classes, but a class can't
> contain a data member or member function with the same name as the class,
> since that name is reserved for the constructor. The Java union mapping gets
> bitten by this too, I think.
It's no problem to have a method X() in a class X in Java, so I
am not sure what you mean here. I agree that unions don't map
particularly well to Java, though, and name clashes can occur
easily. At least they don't backfire at the IDL language definition
and give people headaches that have to fix existing IDL...
Joachim Achtzehnter
> On Wed, 19 Jan 2000, Gerald Brose wrote:
> >
> > "An identifier can only be defined once in a scope. However,
> > identifiers can be redefined in nested scopes. ..."
> >
> The name of an interface, value type, struct, union, exception or
> a module may not be redefined within the immediate scope of
> the interface, value type, struct, union, exception, or the module.
>
> For example:
>
> module M {
> typedef short M; // Error: M is the name of the module
>
> How would you change it to express the intent?
This had me confused, too. In fact, I got the point only after reading
the example. Relying on examples is, of course, not a desireable state
of affairs for a specification.
What makes this confusing, in my opinion, is this: There is a general
statement permitting redefinition in nested scopes. The paragraph
which tries to express the exception to this general rule does NOT
emphasize the fact that it is describing an exception. Confounding
this is the use of the term 'immediate scope' which can easily be
interpreted as a synonym for 'same scope'.
Usually, specifications avoid exceptions to general rules, hence the
unsuspecting reader does not anticipate such an exception. With this
frame of mind one can easily read the second paragraph as an
illustration of the first.
To better express the intent I would recommend to explicitly state in
the second paragraph that it describes an exception to the general
rule in the first paragraph. The term 'immediate scope' should be
replaced by a more precise term like 'immediately nested scope'.
Even better, perhaps, the exception can be pointed out together with
the general rule ("An identifier can only be defined once in a scope,
and can also not be redefined in an immediately nested scope, it can
be redefined in scopes nested two levels below or beyond").
The root cause of the confusion, of course, is the fact that a general
rule is not really general. This is very undesireable. Given that this
exception was introduced because of problems in particular language
mappings (important languages perhaps, but still!) one may ask whether
it would have been better to deal with this problem in the language
mappings that have problems, e.g. prepend the names that collide with
constructors with an underscore. Of course, it is too late for this
now...
Joachim
--
joa...@kraut.bc.ca (http://www.kraut.bc.ca)
joa...@mercury.bc.ca (http://www.mercury.bc.ca)
Michi Henning
> It's no problem to have a method X() in a class X in Java, so I
> am not sure what you mean here. I agree that unions don't map
> particularly well to Java, though, and name clashes can occur
> easily.
I looked at this once and found that certain unions are not mappable.
But you are right, the Java mapping doesn't suffer from this as much
as the C++ mapping.
> At least they don't backfire at the IDL language definition
> and give people headaches that have to fix existing IDL...
Well, there was little else we could do. We considered changing the
C++ mapping to mangle names somehow, but that was very ugly. Fixing it
in IDL also means that no future language mappings has to worry about those
kinds of clashes.
Stephen Crawley
Joachim Achtzehnter <joa...@kraut.bc.ca> wrote:
>[SNIP]
>The root cause of the confusion, of course, is the fact that a general
>rule is not really general. This is very undesireable. Given that this
>exception was introduced because of problems in particular language
>mappings (important languages perhaps, but still!) one may ask whether
>it would have been better to deal with this problem in the language
>mappings that have problems, e.g. prepend the names that collide with
>constructors with an underscore. Of course, it is too late for this
>now...
I think that this comes under the class of fixes that Michi described
as ugly name mangling. The Core & C++ RTF considered them, and decided
that restricting IDL is a better approach.
As we all know, the implicit goals of CORBA IDL include:
* lots of nice OO features & expressiveness,
* a clean / simple IDL language definition, and
* the ability to map cleanly to lots of existing languages, some of
which are neither clean or simple.
Unfortunately, these three goals do not fit together well. When they
conflict (and this is just one example) one or more goal needs to be
compromised.
CORBA is all about compromises. It has to be, otherwise there would
be 20 zillion different CORBA variants, and no interoperability.
Sometimes the compromises look ugly to the bystander, but usually the
alternatives are uglier.
-- Steve
amit...@my-deja.com
> > Given that this
> >exception was introduced because of problems in particular language
> >mappings (important languages perhaps, but still!) one may ask
whether
> >it would have been better to deal with this problem in the language
> >mappings that have problems, e.g. prepend the names that collide with
> >constructors with an underscore. Of course, it is too late for this
> >now...
>
> I think that this comes under the class of fixes that Michi described
> as ugly name mangling. The Core & C++ RTF considered them, and
decided
> that restricting IDL is a better approach.
>
> CORBA is all about compromises. It has to be, otherwise there would
> be 20 zillion different CORBA variants, and no interoperability.
> Sometimes the compromises look ugly to the bystander, but usually the
> alternatives are uglier.
>
> -- Steve
>
who is working in languages like Java ?
Know what I have ten different ways to do a particular thing and I am
struggling to find out 10 different names to do the same thing (or
trying to complicate the code using unions), just because idl does not
support overloaded methods.
Regards,
Amit Unde
Gerald Brose
[...]
> I think that this comes under the class of fixes that Michi described
> as ugly name mangling. The Core & C++ RTF considered them, and decided
> that restricting IDL is a better approach.
>
>
> * lots of nice OO features & expressiveness,
>
> * a clean / simple IDL language definition, and
>
> * the ability to map cleanly to lots of existing languages, some of
> which are neither clean or simple.
>
> Unfortunately, these three goals do not fit together well. When they
> conflict (and this is just one example) one or more goal needs to be
> compromised.
>
> be 20 zillion different CORBA variants, and no interoperability.
> Sometimes the compromises look ugly to the bystander, but usually the
> alternatives are uglier.
Sure, CORBA is about compromises. But perhaps there have been a few
compromises too many and too few rock solid basic principles as
to what may be added or embraced and what should better be ignored.
I don't think you can win any customers with the current complexity
and ugliness of the basic IDL object model anymore - other than those
who technically simply have no alternative.
Perhaps that is just the way things go and I shouldn't be complaining.
At the beginning, there is a stringent model that is practical,
aesthetically acceptable and intelligible. And incomplete. As
lots of more or less useful features are added, the original
clarity is lost and complexity slowly but steadily begins to deter
newcomers until only the die-hards experts remain (who will be
very expensive, of course, so I definitely should not be
complaining ;-)).
I am not a promoter of the Java platform, but Java has developed
simpler answers to many of the more central technical issues and
happily ignores some of the more remote areas which strikes me as
being a better compromise at times.
<sentiment>
Perhaps warding off a few additions (where disadvantages appear to
outweigh the gains like with OBV, IMHO) and restrictions (especially
those from the C++ side ;-)) might have preserved a bit more of
the original CORBA appeal. Of course, this is all purely non-tech
and philosophical, but do you still *like* CORBA?
</sentiment>
Regards, Gerald.
Michi Henning
> Don't you think that these restrictions are too stringent for somebody
> who is working in languages like Java ?
> Know what I have ten different ways to do a particular thing and I am
> struggling to find out 10 different names to do the same thing (or
> trying to complicate the code using unions), just because idl does not
> support overloaded methods.
Well, show me a way to make overloaded methods work in usable way for
the C or COBOL binding, and we can start talking about supporting this...
Ruslan Shevchenko
>
> On Thu, 20 Jan 2000 amit...@my-deja.com wrote:
>
> > Don't you think that these restrictions are too stringent for somebody
> > who is working in languages like Java ?
> > Know what I have ten different ways to do a particular thing and I am
> > struggling to find out 10 different names to do the same thing (or
> > trying to complicate the code using unions), just because idl does not
> > support overloaded methods.
>
> Well, show me a way to make overloaded methods work in usable way for
> the C or COBOL binding, and we can start talking about supporting this...
>
By mangling singnature of the method in method name, in the same way,
as C++ overloaded names mapped to "different" .proc entries in result
object files.
Steve Vinoski
"Ruslan Shevchenko" <Rus...@Shevchenko.Kiev.UA> wrote in message
news:3886F5D5...@Shevchenko.Kiev.UA...
> Michi Henning wrote:
> >
> > On Thu, 20 Jan 2000 amit...@my-deja.com wrote:
> >
> > > Don't you think that these restrictions are too stringent for somebody
> > > who is working in languages like Java ?
> > > Know what I have ten different ways to do a particular thing and I am
> > > struggling to find out 10 different names to do the same thing (or
> > > trying to complicate the code using unions), just because idl does not
> > > support overloaded methods.
> >
> > Well, show me a way to make overloaded methods work in usable way for
> > the C or COBOL binding, and we can start talking about supporting
this...
> >
>
> By mangling singnature of the method in method name, in the same way,
> as C++ overloaded names mapped to "different" .proc entries in result
> object files.
Umm, no. The result would be too impractical to program against. What Michi
meant was to show him a *practical* way of supporting overloading in
languages that don't support it.
--steve
--
Steve Vinoski vinoski at iona.com
Chief Architect 1-800-ORBIX-4U
IONA Technologies, Inc. Waltham, MA USA 02451
200 West St. http://www.iona.com/hyplan/vinoski/
Michi Henning
> > Well, show me a way to make overloaded methods work in usable way for
> > the C or COBOL binding, and we can start talking about supporting this...
> >
>
> By mangling singnature of the method in method name, in the same way,
> as C++ overloaded names mapped to "different" .proc entries in result
> object files.
Yes. And that is precisely why overloading isn't supported. Mangled names
are fine for compilers, but not for humans. If we were to use name mangling,
the resulting APIs would become very ugly indeed, to the point of being
unusable from languages like C and COBOL. This would be contrary to
CORBA's architectural goal of supporting heterogeneous environments.
Sorry, but mangled names simply aren't an option for CORBA.
Michi Henning
> The basic idea is that when generating proxies or skeletons for Java, C++ or
> other languages that support overloading, you strip off the suffix from the
> mangled name to get the Java or C++ name. For languages that don't support
> overloading, you don't strip off the suffix.
Sure, I understand how this works. However, it doesn't remove the basic
problem, namely, that C and COBOL users still end up with very ugly APIs.
Overloading is useful, no doubt. However, I don't see it as essential,
given the architectural goals of CORBA. The price you have to pay is too
high for languages that don't support overloading.
Ruslan Shevchenko
Michi Henning wrote:
> On Fri, 21 Jan 2000, Evan Ireland wrote:
>
> > The basic idea is that when generating proxies or skeletons for Java, C++ or
> > other languages that support overloading, you strip off the suffix from the
> > mangled name to get the Java or C++ name. For languages that don't support
> > overloading, you don't strip off the suffix.
>
> Sure, I understand how this works. However, it doesn't remove the basic
> problem, namely, that C and COBOL users still end up with very ugly APIs.
>
> Overloading is useful, no doubt. However, I don't see it as essential,
> given the architectural goals of CORBA. The price you have to pay is too
> high for languages that don't support overloading.
>
O'key: how we can reduce this price ? -- by providing a simplicified mangled
function, using dependences not only from method signature, but from other
properties, which fully determinate the method. For example - from the location
of methid inside interface.
(be more carefull: let we have interface X which have set of methods and
attributes
M(X)), which mapped by the language mapping to L(M(X)).
Ok. M(X) - ordered => so we can map:
interface X {
y1_ret y(y1_in) ;
y2_ret y(y2_in);
}
to
X_y and X_y_1, instead
X_y1_ret_y1_in and X_y2_ret_y2_in
in usial mangling.
One bad thing -- now language name can be changed from the reordering of methods
inside interface. One good thing -- this is compabilitle with old mapping.
So this is not worse, than current situation.
O'key, let we want to use unordered set and have nothing pass to mapping function.
We can ask the user to provide extra information ( unique suffixes).
Examle:
method X
{
y1_ret y(y1_in) raises(y_exp);
y2_ret y(y2_in) raises(y2_exp) with_suffix(_1);
y3_ret y(y3_in) raises(y3_exp) with_suffix(_z);
};
must be mapped to something like next:
class X
{
y1_ret' y(y1_in') throws(y_exp');
y2_ret y(y2_in') throws(y2_exp');
y3_ret' y(y3_in') throws(y3_exp');
}
in languages, which support overloading, but to
X_y
X_y_1
X_y_z
in langages, which does not support overloading.
What we have in this case:
minuses: extra keyword must be added to IDL
rule |if in interface exists method 'y' with suffix 'x', than in
interface we have no method with name 'yx' | must be added to IDL specs.
small change of IR specs (add field to MethodDef).
pluses:
- compability with old mapping rules.
- easy of usage.
I think, that one of proposed methods (2-nd is more elegant) can be used for
supporting of overloading.
(C) 2000 Ruslan Shevchenko. ;)
Michi Henning
> Sure, CORBA is about compromises. But perhaps there have been a few
> compromises too many and too few rock solid basic principles as
> to what may be added or embraced and what should better be ignored.
> I don't think you can win any customers with the current complexity
> and ugliness of the basic IDL object model anymore - other than those
> who technically simply have no alternative.
>
> Perhaps that is just the way things go and I shouldn't be complaining.
> At the beginning, there is a stringent model that is practical,
> aesthetically acceptable and intelligible. And incomplete. As
> lots of more or less useful features are added, the original
> clarity is lost and complexity slowly but steadily begins to deter
> newcomers until only the die-hards experts remain (who will be
> very expensive, of course, so I definitely should not be
> complaining ;-)).
Two comments: I don't see how the current IDL object model is any more
complex than the one as of three or four years ago. Basically, the only
changes that were made of any significance are the addition of the
new types (fixed, wchar, long long, etc.) and OBV. You can choose to
ignore either, if you wish.
As for IDL having been "stringent" and "aesthetically acceptable and
intelligible" in the beginning, I'm not so sure myself. I see a number of
fundamental mistakes that were made in IDL. These are my pet peeves:
1) Oneway is an abomination that should never have been in IDL.
Not because it's underspecified, but because it has no
place in the object model. After all, oneway does not concern
an aspect of the type system, but an aspect of call dispatch.
Why is it that oneway then is part of IDL, when all other parts
of IDL deal with the type system?
The fact that oneway doesn't belong in IDL is amply demonstrated
by the fact that, using the DII, you can invoke a twoway operation
as if it were oneway. That is clear proof that oneway has
nothing to do with the type system at all and therefore shouldn't
be in IDL. Another telling fact is that oneway operations and
twoway operations map to APIs with exactly the same signature and
therefore, by definition, have nothing to do with the type system.
2) Context are an abomination that should never have been in IDL.
They shoot a huge hole through the type system and are just
plain evil.
3) Attributes were a stupid idea. For one, they don't allow
user exceptions, which makes them second-class citizens.
Second, they are no more than a notational convenience. However,
the gain of that notational short-hand is so small that it
would have better been left out. There is no need for two
ways to say the same thing. (At least the components spec
has made it possible to add user exceptions to attributes,
so I can actually get decent error reporting. But it will have
to wait for CORBA 3.0...)
4) Exceptions don't support inheritance. That turns out to be
quite a pain, because there are no acceptable work-arounds.
At least single inheritance could have been supported quite
easily. Back-patching exception inheritance now is near-enough
impossible because it would break so much code (both vendor
and customer code), it's not funny.
5) The idea of a nil IOR value is misguided. It leads to the
situation where the receiver of an IOR cannot ever risk using
it without testing for nil first. Depending on the language
mapping, not testing first is to risk a core dump.
Nil IORs are evil almost all of the time because, for the vast
majority of calls, they don't ever happen. Yet, the concept
of a nil IOR is not visible in the type system at all.
It would have been far better to have a marker in the type
system that indicates whether a particular IOR can be nil
or not. For example, you could have done something like:
void op(in MyInterface [nil] myparam);
Don't get hung up about the syntax -- the point is that, by
making the concept of nil visible at the type level, you can
write language mappings that don't have to deal with the
bloody nil threat all the time.
For example, with this, you could map IORs to two different
language constructs. One would be an IOR object that cannot
be nil, and attempts to put a nil value into it would raise
a run-time error. Then, all parameters and members for non-nil
IORs could use that non-nil IOR object in the mapping.
For IORs that can be optionally nil, you wrap the non-nil
object into another object, with accessors to set and get
the nil IOR (if it is nil). Attempts to extract a nil value
into the non-nil IOR object type would raise an exception.
What this boils down is that you could just blindly use most
IORs that you receive without having to test for anything.
(You wouldn't have to pay for what you don't use.) For IORs
that could be nil, the cost would be no greater than what we
have now, except that now, we have to incur the cost all the
time.
6) Use of the preprocessor for IDL was a stupid idea. It's been
known to be evil for more than twenty years, yet, no-one
thought it worth learning from the mistakes of the past.
A proper import mechanism in its place would have
saved an awful lot of headaches (some of which are still
unresolved; for example, what happens if you #include an IDL
file at anything but the global scope is anybody's guess).
Fortunately, the components spec has added an import
mechanism, so we may be able to put a stake through the heart
of the proprocessor soon.
7) Constant expressions have gone way overboard. For one, the
bitwise operators for constants are about as useful as
a hole in the head at the level of abstraction IDL operates on.
Besides, contrary to what we said in the book, IDL does not
guarantee two's complement representation so, in fact, what
the bitwise operators do is, strictly speaking, totally undefined.
For the arithmetic operators, the situation isn't much better.
Mixed-mode arithmetic was banned, at least, but, even so,
the semantics of these operators are very dubious. Modulo 2
arithmetic is not guaranteed, so what happens in case of
overflow or narrowing conversions is completely undefined.
In fact, the entire notion of constant expressions could have
probably been thrown out without any real loss. Constant
definitions using literals are just as useful, as a rule.
(In the rare cases where you would like to use a constant
expression you can just as well use a literal with a comment.
After all, these are *compile-time* constant expressions, meaning
that they rarely change, if ever.)
8) Unions and Anys are so similar, it's not funny. Yet, I can't
use one as the other. In addition, unions got bitten by the
feature creature, which has blessed us with multiple case
labels per member and a default case. Both of these are a royal
pain to use at the language mapping level. Having these features
was considered necessary even though, to the best of my knowledge,
no language that supports discriminated unions supports either
multiple case labels or a default case...
It would have been better to use type Any, augmented with
a way to restrict its contents to specific types. That would
have eliminated unions, and simplified both the APIs and
the marshaling code.
9) Using #pragma for repository IDs (in fact, using #pragma for
*anything*) is evil. This comes under the general heading
of "preprocessor insanity". Because #pragma is completely
outside the normal syntax of the language, you can do utterly
stupid things with it (such as introducing a prefix pragma
in the middle of a scope, or even doing something like:
union U
#pragma prefix "foo"
switch (boolean) {
case TRUE:
long val;
#pragma prefix "bar"
case FALSE:
string s;
};
That's just plain silly.
10) The restriction that you cannot inherit the same operation or
attribute name more than once for multiple inheritance can
be painful. It wouldn't have been too hard to come up with
a resolution for that one.
> I am not a promoter of the Java platform, but Java has developed
> simpler answers to many of the more central technical issues and
> happily ignores some of the more remote areas which strikes me as
> being a better compromise at times.
I'm not sure where Java comes into this discussion. Java is just another
programming language. IDL isn't a programming language but a type definition
language. Java's type model is remarkably similar to the IDL type model.
So, as far as the type model is concerned, I don't see where Java has done
better or worse. Aren't you comparing apples and oranges here?
> <sentiment>
> Perhaps warding off a few additions (where disadvantages appear to
> outweigh the gains like with OBV, IMHO) and restrictions (especially
> those from the C++ side ;-)) might have preserved a bit more of
> the original CORBA appeal. Of course, this is all purely non-tech
> and philosophical, but do you still *like* CORBA?
> </sentiment>
Yes, I still like CORBA. Despite the rave above, it runs rings around
everything else that can be used for vaguely the same purpose. And,
I really have to ask: is it really such an onerous restriction that
you cannot write:
struct S {
long S;
};
Personally, programmers who write that kind of thing around here get
rapped on the knuckles because, at best, it is poor style and, at worst,
it's sabotage of my project...
If you write clean IDL with reasonably unique names for you types (as you
should anyway), you never have to come near the rules that deal with
various boundary cases. OMG IDL is simpler than any other IDL I know of.
I don't think it could be made much simpler than it is (sans the rave I
wrote above ;-)
What you perceive as complexity of IDL really isn't, in my opinion. It
turns out that any type definition language must deal with things such
as scope resolution rules, lookup order, precedence, namespace collisions,
etc, etc. IDL is no more complex than any other language with roughly the
same expressiveness. IDL originally appeared simple because it didn't
bother to specify most of these things. However, that didn't make IDL
simple, it just made it non-portable. Over the years, we've systematically
worked to plug those underspecified holes. That makes IDL a more portable
(and therefore better) language. It also creates an impression of
complexity. But, when you are honest about it, that complexity was always
there. It's just that it wasn't standardized...
Stephen Crawley
>> CORBA is all about compromises. It has to be, otherwise there would
>> be 20 zillion different CORBA variants, and no interoperability.
>> Sometimes the compromises look ugly to the bystander, but usually the
>> alternatives are uglier.
>>
>>
>Don't you think that these restrictions are too stringent for somebody
>who is working in languages like Java ?
No.
The reasons for nearly all of the ugly compromises in CORBA IDL and
the various language mappings is that CORBA IDL aims to be programming
language independent. If you tried to make IDL more Java friendly,
you'd probably make it less friendly for C or C++ or Ada or whatever.
If you really want to do distributed programming in Java (only),
you should consider using JNI instead of CORBA. Otherwise, you
must learn to live with the consequences of trying to support
multiple languages.
>Know what I have ten different ways to do a particular thing and I am
>struggling to find out 10 different names to do the same thing (or
>trying to complicate the code using unions), just because idl does not
>support overloaded methods.
You are in no different position to someone who is writing programs in
C and a number of other languages I could name that don't support
overloading. As Michi said in another branch, CORBA IDL does not
support overloading because the name mangling schemes to make it work
in some languages are too ugly to contemplate.
Note that when we (Michi, Steve V, me and others) say "ugly" we mean
things like:
* names that are a zillion characters long
* names that cannot be predicted by reading the
source IDL ... unless you are a language lawyer
* names that change when you make a seemingly irrelevant
change to the IDL
"Ugliness" makes it lots harder to code against the APIs, harder
to read the code, and harder still to maintain it.
-- Steve
Stephen Crawley
Michi Henning <mi...@ooc.com.au> wrote:
>On Thu, 20 Jan 2000, Gerald Brose wrote:
>
>> Sure, CORBA is about compromises. But perhaps there have been a few
>> compromises too many and too few rock solid basic principles as
>> to what may be added or embraced and what should better be ignored.
>> I don't think you can win any customers with the current complexity
>> and ugliness of the basic IDL object model anymore - other than those
>> who technically simply have no alternative.
>>
>> Perhaps that is just the way things go and I shouldn't be complaining.
>> At the beginning, there is a stringent model that is practical,
>> aesthetically acceptable and intelligible. And incomplete. As
>> lots of more or less useful features are added, the original
>> clarity is lost and complexity slowly but steadily begins to deter
>> newcomers until only the die-hards experts remain (who will be
>> very expensive, of course, so I definitely should not be
>> complaining ;-)).
>
>Two comments: I don't see how the current IDL object model is any more
>complex than the one as of three or four years ago. Basically, the only
>changes that were made of any significance are the addition of the
>new types (fixed, wchar, long long, etc.) and OBV. You can choose to
>ignore either, if you wish.
Gerald might be referring to some of the changes in the scoping rules
that have happened in 2.2 & 2.3. The restriction that sparked this
thread is a case in point.
In general, it is fair to say that the scoping rule changes in the IDL
spec were all made because they were necessary. Many of them amount
to writing down rules to cover cases for which no rules previously
existed. For example, if you look at CORBA 2.0 / 2.1 you'll have
great difficulty understanding when you are or are not allowed to
redeclare an identifier. The words ain't there, and as a result
different IDL compilers would accept/reject different IDL.
The remaining changes were made to fix problems where paricular IDL
could not be mapped to a popular target language (e.g. C++) without
trashing the usability of the language mapping.
Gerald can say that CORBA IDL was simpler three or four years ago.
But in this area, it was also broken.
-- Steve
amit...@my-deja.com
> >>
> >Don't you think that these restrictions are too stringent for
somebody
> >who is working in languages like Java ?
>
> No.
>
> The reasons for nearly all of the ugly compromises in CORBA IDL and
> the various language mappings is that CORBA IDL aims to be programming
> language independent. If you tried to make IDL more Java friendly,
> you'd probably make it less friendly for C or C++ or Ada or whatever.
>
Not Java friendly. But, atleast, it should have been "Object-oriented
Language" friendly.
Agreed that name mangling scheme makes it harder to code for some
languages . But, in this case, you could simply opt not to use these
features in idl.
Why to restrict languages which can support these features ?
When you are sure, that your idl is going to be mapped only for object
oriented languages, then use these features otherwise stick to the
restrictions.
Am I missing something ?
- Amit
Michi Henning
> > The reasons for nearly all of the ugly compromises in CORBA IDL and
> > the various language mappings is that CORBA IDL aims to be programming
> > language independent. If you tried to make IDL more Java friendly,
> > you'd probably make it less friendly for C or C++ or Ada or whatever.
> >
>
> Not Java friendly. But, atleast, it should have been "Object-oriented
> Language" friendly.
> Agreed that name mangling scheme makes it harder to code for some
> languages . But, in this case, you could simply opt not to use these
> features in idl.
No, you cannot. Most often, I have to use the IDL written someone else.
> Why to restrict languages which can support these features ?
> When you are sure, that your idl is going to be mapped only for object
> oriented languages, then use these features otherwise stick to the
> restrictions.
> Am I missing something ?
Yes. IDL gets written once by someone. Then lots of people go and writer
clients ands servers for that IDL. (The OMG specifications are a prime
example.) You simply cannot assume that the author of the IDL and the
author of the code are one and the same.
Martin v.Loewis
Ruslan Shevchenko <Rus...@Shevchenko.Kiev.UA> wrote:
>O'key: how we can reduce this price ? -- by providing a simplicified mangled
>function, using dependences not only from method signature, but from other
>properties, which fully determinate the method. For example - from the location
>of methid inside interface.
I can't see the point of this discussion, nor this proposal.
First, I believe there is no bug to fix here. So far, the only rationale
for having overloading in IDL is "because Java has it" (C++ also has
overloading, but that never appears to be a motivation). I'd be more
interested in seeing real-world examples where not having overloading
(in IDL!) is a serious restriction. I'm not so much interested in toy
examples; it is always easy to come up with toy examples.
Next, I'm not certain whether your proposal was just thrown to show that
one can find a hack, or whether it was meant as a serious proposal for an
extension of IDL. If so, it seems it lacks in quite a number of areas.
Ideas are a dime a dozen, as they say. Do you have an implementation of this
proposal, showing that it actually works? Do you have users of this
technique, so there is experience whether the feature is actually used?
For such a change in IDL, a dozen or so implementations of CORBA must
change, and it will take years until the feature is widely available.
If you change the foundations of CORBA, you must have *really* good
reasons, or ORB implementors will just ignore you.
Regards,
Martin
Gerald Brose
>
> On Thu, 20 Jan 2000, Gerald Brose wrote:
>
> Two comments: I don't see how the current IDL object model is any more
> complex than the one as of three or four years ago. Basically, the only
> changes that were made of any significance are the addition of the
> new types (fixed, wchar, long long, etc.) and OBV. You can choose to
> ignore either, if you wish.
I have no objections to those new base types. Actually, it is OBV
that really gives me the creep and the main point behind my complaints.
(No, unfortunately I cannot ignore it, it's there and people ask
for it and use it)
Let's go on with this raving business a little: IMHO trying to
express which parameter passing semantics should apply by
introducing an extra category of hybrid types and another
category of interfaces is plain nonsense from a language design
point of view. I presume it had to be done this way because that's
how it's done in Java (which in my view is also silly) but if
anyone can enlighten me about the actual rational behind this I
would be grateful.
Languages like Pascal and Modula had a nice little keyword like "VAR"
in parameter declarations (Eiffel used "expanded"). That way every-
thing that needed to be said could be said and no new hybrid type
had to be added to teh language. (That state members are needed in
IDL is granted, of course).
The other point is IDL vs. PIDL vs. locality constrained (plus
actually another kind of "locality constrained", viz. calls to
"objects" like the POA itself which are not dispatched by the
POA itself, of course.) This is a historical point only.
> As for IDL having been "stringent" and "aesthetically acceptable and
> intelligible" in the beginning, I'm not so sure myself. I see a number of
> fundamental mistakes that were made in IDL. These are my pet peeves:
> [...]
Thanks for your extensive and interesting comments. What I liked
about IDL was being clear about what a reference type and a non-
reference type was.
> > I am not a promoter of the Java platform, but Java has developed
> > simpler answers to many of the more central technical issues and
> > happily ignores some of the more remote areas which strikes me as
> > being a better compromise at times.
>
> I'm not sure where Java comes into this discussion. Java is just another
> programming language. IDL isn't a programming language but a type definition
> language. Java's type model is remarkably similar to the IDL type model.
> So, as far as the type model is concerned, I don't see where Java has done
> better or worse. Aren't you comparing apples and oranges here?
I was referring to Java as a *platform*, not as a language. The Java
platform offers quite a few goodies with regard to distributed
computing by now which are applicable in a good many situations
while of course not covering the whole ground CORBA covers. But it's
usually simpler to use. (RMI-IIOP, JNDI, Servlets, ...)
> > <sentiment>
> > Perhaps warding off a few additions (where disadvantages appear to
> > outweigh the gains like with OBV, IMHO) and restrictions (especially
> > those from the C++ side ;-)) might have preserved a bit more of
> > the original CORBA appeal. Of course, this is all purely non-tech
> > and philosophical, but do you still *like* CORBA?
> > </sentiment>
>
> Yes, I still like CORBA.
Glad to hear that :-)
> What you perceive as complexity of IDL really isn't, in my opinion. It
> turns out that any type definition language must deal with things such
> as scope resolution rules, lookup order, precedence, namespace collisions,
> etc, etc.
Sure, I wrote an IDL compiler myself (which now needs a bit of
2.3 tweaking with regard to name spaces) and agree that these
things are just plain necessary. That namespace rules have got
a bit less straightforward from a non-C++ perspective lately
was discovered in earlier postings.
> IDL is no more complex than any other language with roughly the
> same expressiveness. IDL originally appeared simple because
> it didn't bother to specify most of these things.
> It also creates an impression of
> complexity. But, when you are honest about it, that complexity
> was always there. It's just that it wasn't standardized...
I only object to a) adding useless complexity and b) muddling
up IDL rather than make individual language mappings more complex
when you discover that certain IDL features are not as easy to
map as they might have appeared at first sight. After all, unions
weren't abolished just because they are a pain to map to Java,
(sorry, I can't find a better example right now).
Martin v.Loewis
>intelligible" in the beginning, I'm not so sure myself. I see a number of
>fundamental mistakes that were made in IDL.
Michi,
That's an excellent list, and I agree with all of them. Would you care posting
in a more permanent location than a Usenet article?
Anyway, there are some more things that I feel are odd
11) Arrays are not really needed, when you have sequences.
12) Anonymous types are evil. I happily noticed that they are deprecated.
With arrays gone, sequences could have become a first-order concept:
sequence FooSeq Foo; //Now: typedef sequence<Foo> FooSeq;
13) Declaring more than one entity in a single declaration, as in
struct S{
long a, b[10], c;
};
is not really needed, and complicates tools somewhat. This is a minor
nit, but it is there only because of the C heritage, and it is
inconsistent. Why can't you write
interface A,B,C; //forward declarations
const long a=5,b=6; // but constants are evil, anyway
interface I{
void foo(in string given_name,mi,surname);
};
Regards,
Martin
Martin v.Loewis
Gerald Brose <br...@inf.fu-berlin.de> wrote:
>Let's go on with this raving business a little: IMHO trying to
>express which parameter passing semantics should apply by
>introducing an extra category of hybrid types and another
>category of interfaces is plain nonsense from a language design
>point of view. I presume it had to be done this way because that's
>how it's done in Java (which in my view is also silly) but if
>anyone can enlighten me about the actual rational behind this I
>would be grateful.
I can't quite understand this comment, perhaps I miss some background.
Are you referring to abstract interfaces here, only, or to valuetypes
in general?
valuetypes are more than just a way of passing things by value. They
are really what structs should have been in the first place. They allow
you recursive and polymorphic data structures, which was not possible
before, and is quite useful.
abstract interfaces, OTOH, may be debatable. I don't really know what
the *true* rationale behind those is. I cannot see the need to pass
a thing sometimes as value, and sometimes as an object reference.
It looks like a terribly complex concept, with little usability.
Regards,
Martin
Raymond Wiker
> In article <Pine.HPX.4.05.100012...@bobo.ooc.com.au>,
> Michi Henning <mi...@ooc.com.au> wrote:
> >As for IDL having been "stringent" and "aesthetically acceptable and
> >intelligible" in the beginning, I'm not so sure myself. I see a number of
> >fundamental mistakes that were made in IDL.
>
> Michi,
>
> That's an excellent list, and I agree with all of them. Would you care posting
> in a more permanent location than a Usenet article?
>
> Anyway, there are some more things that I feel are odd
[ snip ]
Some more:
14) Basing IDL syntax on C/C++ was/is a bad idea (not expressive
enough, and in some areas the IDL syntax ended up being different from
what was eventually adopted for C++).
15) (Related to 14) "Borrowing" the basic type names from
C/C++, but adding stricter semantics (e.g, specific bit lengths for
the various integer types) is just plain dumb. Why not use something
like int16, or int(16) - even int(-32768, 32767) would be better :-)
--
Raymond Wiker, Orion Systems AS
+47 370 61150
Michi Henning
> That's an excellent list, and I agree with all of them. Would you care posting
> in a more permanent location than a Usenet article?
Hmmm... I guess I could hack something up for my web page. Will do when I
get a moment...
> Anyway, there are some more things that I feel are odd
>
> 11) Arrays are not really needed, when you have sequences.
Yes and no. I guess the question is whether or not the added type safety is
worth it. An array guarantees that *exactly* n things will be sent/received,
whereas a bounded sequence only guarantees that *no more than* n things
will be sent/received. Sometimes, the added type safety is appreciated.
But it begs the question: is it really necessary to have arrays in the presence
of sequences for a minor gain in type safety? Me feeling is that, in general,
the answer is probably no. I'm saying that because arrays substantially add
to the size of the code and the complexity of the APIs you have to use.
Also, I can't take full advantage of the added type safet. For example,
the one place where I really would like to use arrays is for recursive data
types. For example:
struct BinaryNode; // Forward declaration; will be legal
// in CORBA 3.0
typedef BinaryNode BinaryChildren[2];
struct BinaryNode {
SomeType value;
BinaryChildren children; // Not legal IDL!
};
I would like to use an array for the recursion to make sure that a binary
node has *exactly* two children. Unfortunately, I'm not allowed to recurse
via an array, so this doesn't work. Given that arrays are second-class
citicens in this sense, it is doubtful whether their presence in IDL
is really justified.
> 12) Anonymous types are evil. I happily noticed that they are deprecated.
> With arrays gone, sequences could have become a first-order concept:
> sequence FooSeq Foo; //Now: typedef sequence<Foo> FooSeq;
Well, the deprecation of anonymous types is the result of a three-year
crusade of mine. Unfortunately, we still have one kind of anonymous type
that hasn't been deprecated:
typedef long MyType[10][20];
The row type of this array is anonymous, and such definitions have not
been deprecated. The consensus was that it would be too onerous to force
a typedef:
typedef long RowType[20];
typedef RowType MyType[10];
Other than that, I think we've managed to deprecate all other kinds of
anonymous type (but it will be years before we can make them illegal...)
At least, IDL compilers can choose to emit warnings for anonymous types now.
> 13) Declaring more than one entity in a single declaration, as in
> struct S{
> long a, b[10], c;
> };
> is not really needed, and complicates tools somewhat. This is a minor
> nit, but it is there only because of the C heritage, and it is
> inconsistent.
Well, that's a result of the C/C++ heritage. (The fact that the C declaration
syntax is brain-dead notwithstanding... On the other hand, you can argue
that there is a lot to be said for familiarity and that IDL's similarity
to C++ has probably contributed a lot toward its popularity and acceptance.
Or, if you like, you could call this a professional marketing con-job ;-)
> Why can't you write
>
> interface A,B,C; //forward declarations
> const long a=5,b=6; // but constants are evil, anyway
Yes, that's inconsistent with C syntax. On the other hand, I hardly ever
use constants anyway. When I do, I define one constant per declaration
as a matter of style, so I'm not worried about this syntactical nit.
> interface I{
> void foo(in string given_name,mi,surname);
> };
No, that's consistent. The equivalent in C isn't legal either -- you must
have a separate type for every parameter.
Michi Henning
> Some more:
>
> 14) Basing IDL syntax on C/C++ was/is a bad idea (not expressive
> enough, and in some areas the IDL syntax ended up being different from
> what was eventually adopted for C++).
Hmmm... I'm not so sure about this. Despite the fact that C declaration syntax
is awful, I think it was important that IDL looked a lot like a C++ class
definition. It meant that people could learn IDL in about 2 hours flat...
Could you be more specific about what you mean by "not expressive enough"?
I don't know what you are referring to here. Also, do you have specific
examples where the syntax differs? (I know there are some differences but,
in general, there are good reasons for them.) It might be interesting to
see whether any of these are ill-motivated.
> 15) (Related to 14) "Borrowing" the basic type names from
> C/C++, but adding stricter semantics (e.g, specific bit lengths for
> the various integer types) is just plain dumb. Why not use something
> like int16, or int(16) - even int(-32768, 32767) would be better :-)
That's just a matter of naming and a minor point, IMO. The fact that
IDL specified minimum guaranteed ranges for integers was a big gain, IMO --
no more guessing games as to whether an int is two or four bytes... ;-)
Michi Henning
> We can ask the user to provide extra information ( unique suffixes).
>
> Examle:
>
> method X
> {
> y1_ret y(y1_in) raises(y_exp);
> y2_ret y(y2_in) raises(y2_exp) with_suffix(_1);
> y3_ret y(y3_in) raises(y3_exp) with_suffix(_z);
> };
>
> must be mapped to something like next:
> class X
> {
> y1_ret' y(y1_in') throws(y_exp');
> y2_ret y(y2_in') throws(y2_exp');
> y3_ret' y(y3_in') throws(y3_exp');
> }
>
> in languages, which support overloading, but to
>
> X_y
> X_y_1
> X_y_z
>
> in langages, which does not support overloading.
No, that's not the way to do it. IDL is a type definition language. If you
were to augment IDL with things such as the suffixes you suggest, you would
take the first step toward making IDL both a type definition language and
a language mapping definition language. That's not a good idea because it
mixes unrelated concepts into the same language. (That's the same thing as
oneway -- I keep arguing that oneway doesn't belong in IDL because it
deals with an orthogonal concept.)
> What we have in this case:
> minuses: extra keyword must be added to IDL
> rule |if in interface exists method 'y' with suffix 'x', than in
> interface we have no method with name 'yx' | must be added to IDL specs.
> small change of IR specs (add field to MethodDef).
> pluses:
> - compability with old mapping rules.
> - easy of usage.
>
> I think, that one of proposed methods (2-nd is more elegant) can be used for
> supporting of overloading.
Well, how would it work in the presence of inheritance? In the presence
of multiple inheritance? What parts of the signature are relevant for
overloading? The parameters only? The return type as well? The exception
specification? The context clause? The oneway operation attribute?
What if one or more of the target languages don't support overloading on
return type (covariant return types), as C++ did for a long time?
Which operations in base interfaces can be overloaded in derived interfaces
and according to what rules? Which multiply inherited overloaded operations
are considered to be ambiguous under what circumstances? Can attributes
be overloaded? What about value types? Abstract value types? (The list of
questions you would really have to ask is likely quite a bit longer...)
This list of questions serves to illustrate the kinds of things you must
think about when you propose a change to the spec. Further questions you
must find answers for:
How much code gets broken by the change?
How intrusive is the change to existing ORB implementations?
Can the change supported in a backward compatible way so older
clients can talk to newer servers?
Does the change affect the GIOP/IIOP protocol? If so, what conformance
and compatibility requirements are necessary?
On and on it goes... (Gee -- I'm beginning to sound like Bjarne... ;-)
Remember, every time we touch something in the CORBA spec, we affect tens
of thousands of programmers. While it is fun to innovate and to play in
the standards game, there is also a lot responsibility that goes with it
because every time we screw up, potentially tens of thousands of programmers
suffer.
We considered various name mangling schemes in order to support overloading
in the past. We rejected them because we have a responsibility not only
toward the existing C++ and Java user base, but toward the *entire* CORBA
user base, which includes C and COBOL programmers (and, soon, PL/1
programmers). We can't just tell all these people to go and jump in a lake
(or, at least, we can't if we have any sort of conscience, let alone
business sense ;-)
Gerald Brose
"Martin v.Loewis" wrote:
>
> In article <38881571...@inf.fu-berlin.de>,
> Gerald Brose <br...@inf.fu-berlin.de> wrote:
>
> >Let's go on with this raving business a little: IMHO trying to
> >express which parameter passing semantics should apply by
> >introducing an extra category of hybrid types and another
> >category of interfaces is plain nonsense from a language design
> >point of view. I presume it had to be done this way because that's
> >how it's done in Java (which in my view is also silly) but if
> >anyone can enlighten me about the actual rational behind this I
> >would be grateful.
>
> I can't quite understand this comment, perhaps I miss some background.
> Are you referring to abstract interfaces here, only, or to valuetypes
> in general?
I was referring to both of them.
> valuetypes are more than just a way of passing things by value. They
> are really what structs should have been in the first place. They allow
> you recursive and polymorphic data structures, which was not possible
> before, and is quite useful.
I was taking a language design point of view here. From this per-
spective, having structs AND interfaces AND value types AND abstract
interfaces is not really acceptable as each of these concepts
overlaps with one or two others.
From a more pragmatic point of view you may argue, as you did, that
value types fix an earlier language defect and that deprecating
structs simply was no option. I would not argue with that. I am
only saying that the resulting object model is not something you
would regard as a clear design.
Raymond Wiker
> On Fri, 21 Jan 2000, Raymond Wiker wrote:
>
> > Some more:
> >
> > 14) Basing IDL syntax on C/C++ was/is a bad idea (not expressive
> > enough, and in some areas the IDL syntax ended up being different from
> > what was eventually adopted for C++).
>
> Hmmm... I'm not so sure about this. Despite the fact that C declaration syntax
> is awful, I think it was important that IDL looked a lot like a C++ class
> definition. It meant that people could learn IDL in about 2 hours flat...
I'm not trying to start a fight here, but I don't think that
it would take longer to learn IDL if it used a syntax more obviously
different from C++. After all, there are differences from C++ syntax
(in, out, inout, const operations, boolean vs bool, module vs
namespace, sequence vs list, tagged unions, ...) which you must keep
in my mind when working with IDL.
> Could you be more specific about what you mean by "not expressive enough"?
> I don't know what you are referring to here.
I *think* that I meant that the C++ syntax is a poor notation
for describing interfaces. IDL is a little better, but I think it
could have been much better if similarity to C++ had not been a
goal. Your own criticisms of IDL more than hint at this; the entire
preprocessor debacle[1], including #include and #pragma is also part
of the same problem.
> Also, do you have specific examples where the syntax differs? (I
> know there are some differences but, in general, there are good
> reasons for them.) It might be interesting to see whether any of
> these are ill-motivated.
I mentioned some of them above. Another is the use of <> to
parameterise certain IDL types - this is similar to templates in C++,
but differs in the details. I also think that some of the scoping
rules are different, esp. wrt to file-level scope.
> > 15) (Related to 14) "Borrowing" the basic type names from
> > C/C++, but adding stricter semantics (e.g, specific bit lengths for
> > the various integer types) is just plain dumb. Why not use something
> > like int16, or int(16) - even int(-32768, 32767) would be better :-)
>
> That's just a matter of naming and a minor point, IMO. The fact that
> IDL specified minimum guaranteed ranges for integers was a big gain, IMO --
> no more guessing games as to whether an int is two or four bytes... ;-)
Sure about that :-? I can *never* remember whether a
CORBA::int is 16 or 32 bits. Also, the fact that the type names look
so similar means that it's easy to do something like indexing a CORBA
sequence with unsigned long, just because the CORBA defintion use
CORBA::ULong. This does not work with certain combinations of C++
compilers and ORBs, as CORBA::ULong may be mapped to unsigned int
instead of unsigned long.
Footnotes:
[1] Sense 3a and 3b, from Merriam-Webster's Collegiate Dictionary - I
had to look it up :-)
Michi Henning
> From a more pragmatic point of view you may argue, as you did, that
> value types fix an earlier language defect and that deprecating
> structs simply was no option. I would not argue with that. I am
> only saying that the resulting object model is not something you
> would regard as a clear design.
IMO, the entire OBV thing was a very misguided attempt at making CORBA like
Java, despite the fact that the architectural goals are very different.
In particular, permitting operations on valuetypes has destroyed a
fundamental architectural goal of CORBA, namely, that of implementation
transparency.
Consider: In the absence of value types, IDL is the *only* contract between
client and server. In all other respects, they care completely independent.
Yet, if they agree to use the same IDL, they can communicate, and all
of the transparencies of CORBA are preserved.
Enter OBV... If I create IDL with OBVs that have operations, the picture
changes drastically. I no longer can look at the IDL and communicate with
the server. That's because, unless I have advance knowledge of the
value types I want to use, I'm hosed. What I mean by "advance knowledge"
is that I must have local code that implements the operations on the value
type.
Where does that code come from? Nobody knows...
There is no concept of downloading the code on the fly (apart from Java)
and, even if there were, there is no way to make it work: for example,
the code used by a C++ server on a Linux machine is not terribly useful
to a COBOL client on an MVS machine...
Now, consider the consequences of this. IDL claims to be language,
implementation, and OS transparent. Yet, we have a construct in IDL that
breaks all of these transparencies. Imagine that one of the CORBAservices
used valuetypes with operations, and that you are a vendor who wants to
sell access to that that service. Without OBV, you just run the service
somewhere and anyone can use it. With OBV with operations, you now have
to ship client-side libraries for all possible combinations of programming
language, compiler, compiler versions, operating system, ORB, and ORB version.
That adds up to thousands of possible binary distributions real quick...
Another problem with OBV is the insane amount of complexity it has added
to the protocols. Steve and I keep predicting that it will take years
until the last few bugs are ironed out and different vendor implementations
of OBV will interoperate reliably.
It would have been so much simpler to add inheritance to structs. That would
have given us much of the functionality of OBV without any of the baggage...
Michi Henning
> > Hmmm... I'm not so sure about this. Despite the fact that C declaration syntax
> > is awful, I think it was important that IDL looked a lot like a C++ class
> > definition. It meant that people could learn IDL in about 2 hours flat...
>
> I'm not trying to start a fight here, but I don't think that
> it would take longer to learn IDL if it used a syntax more obviously
> different from C++. After all, there are differences from C++ syntax
> (in, out, inout, const operations, boolean vs bool, module vs
> namespace, sequence vs list, tagged unions, ...) which you must keep
> in my mind when working with IDL.
Maybe so. On the other hand, making it look a lot like C++ *sold*
it really well...
> I mentioned some of them above. Another is the use of <> to
> parameterise certain IDL types - this is similar to templates in C++,
> but differs in the details. I also think that some of the scoping
> rules are different, esp. wrt to file-level scope.
Well, whether you use <> or something else is probably a minor thing. Also,
remember that things like modules and namespaces were developed independently,
so there was no opportunity to align them.
> > That's just a matter of naming and a minor point, IMO. The fact that
> > IDL specified minimum guaranteed ranges for integers was a big gain, IMO --
> > no more guessing games as to whether an int is two or four bytes... ;-)
>
> Sure about that :-? I can *never* remember whether a
> CORBA::int is 16 or 32 bits.
Yes, I'm quite sure. I'm sure because there is no such thing as
a CORBA::int -- there is only short and long ;-)
> Also, the fact that the type names look
> so similar means that it's easy to do something like indexing a CORBA
> sequence with unsigned long, just because the CORBA defintion use
> CORBA::ULong. This does not work with certain combinations of C++
> compilers and ORBs, as CORBA::ULong may be mapped to unsigned int
> instead of unsigned long.
Interesting point. I guess you are referring to ambiguous overloading
problems if you index with an unsigned long on a compiler that uses unsigned
int for CORBA::ULong? Yes, that's a bit of an annoyance. (The same thing
happens on some compilers if you use an int to index a sequence.)
Unfortunately, the C++ type system leaves us little choice here because
it doesn't give size guarantees for integer types. This means that the
C++ mapping cannot be more strict than it is. (But, this really is beside
the point as far as IDL is concerned because it is a C++ issue. And I don't
think that it would be preventable by changing IDL, short of eliminating
different integer sizes completely.)
Evan Ireland
>
> On Thu, 20 Jan 2000, Ruslan Shevchenko wrote:
>
> > > Well, show me a way to make overloaded methods work in usable way for
> > > the C or COBOL binding, and we can start talking about supporting this...
> > >
> >
> > By mangling singnature of the method in method name, in the same way,
> > as C++ overloaded names mapped to "different" .proc entries in result
> > object files.
>
> Yes. And that is precisely why overloading isn't supported. Mangled names
> are fine for compilers, but not for humans. If we were to use name mangling,
> the resulting APIs would become very ugly indeed, to the point of being
> unusable from languages like C and COBOL. This would be contrary to
> CORBA's architectural goal of supporting heterogeneous environments.
> Sorry, but mangled names simply aren't an option for CORBA.
I think that depends on who gets to create the mangled name. The Java to IDL
mapping has already created a precedent for mapping overloaded Java method
names to IDL, so if you have Java:
void myMethod(double d);
void myMethod(float f);
That maps to IDL:
void myMethod__double(in double d);
void myMethod__float(in float f);
When generating Java proxies for this (let's say in the context of RMI/IIOP
for EJB <-> CORBA interoperability), the proxies should use the overloaded
names, not the mangled names.
Now when you overload myMethod with a version with 20 parameters, the mangled
name would be ugly, unless the mangled name itself is human-generated.
The basic idea is that when generating proxies or skeletons for Java, C++ or
other languages that support overloading, you strip off the suffix from the
mangled name to get the Java or C++ name. For languages that don't support
overloading, you don't strip off the suffix.
________________________________________________________________________________
Evan Ireland Sybase EA Server Engineering eire...@sybase.com
Wellington - New Zealand +64 4 934-5856
Evan Ireland
>
> On Fri, 21 Jan 2000, Evan Ireland wrote:
>
> > The basic idea is that when generating proxies or skeletons for Java, C++ or
> > other languages that support overloading, you strip off the suffix from the
> > mangled name to get the Java or C++ name. For languages that don't support
> > overloading, you don't strip off the suffix.
>
> problem, namely, that C and COBOL users still end up with very ugly APIs.
I have three answers for this (the last two are not entirely serious):
(1) It's not that ugly if the end-user chooses the mangling. The automatically
generated mangled names from the Java to IDL mapping can be ugly though.
(2) C users can just switch to C++ if they want it to look nice.
(3) COBOL is ugly anyway, so a few names with two underscores wouldn't matter.
> Overloading is useful, no doubt. However, I don't see it as essential,
> given the architectural goals of CORBA. The price you have to pay is too
> high for languages that don't support overloading.
The way we deal with it is:
(1) Not using overloading in the services we provide and implement.
(2) Allowing our customers to use it but informing them of the portability and
usability consequences.
I think the fact that the Java to IDL standard mapping has actually defined a
name mangling convention for CORBA, it only makes sense to consider how that
should be reflected in the language mappings (e.g. IDL to C++, IDL to Java)
for languages that support overloading.
Martin v.Loewis
>Consider: In the absence of value types, IDL is the *only* contract between
>client and server. In all other respects, they care completely independent.
>Yet, if they agree to use the same IDL, they can communicate, and all
>of the transparencies of CORBA are preserved.
I'm not sure whether this is a good argument against the OBV spec. For
one thing, it is not a valid argument: There is always more contract
between client and server but just IDL. These operations have a semantics
behind them, which might be implicit from the operation names, or
spelled-out in (typically) English text. So you not only have to know what
the operations are, but also how to use them.
There is also environment information needed to use a server. You have to
know how it registered with the naming server, or you have to know some
other bootstrap mechanism. Only part of the contract is specified in IDL,
so I would not worry too much whether you'll have to assume even more
with OBV (like knowledge about some library you use).
Also, this is an architectural complaint. I would not primarily worry about
the architecture, but whether the technology helps solving me problems. If
the technology is useful, and it violates the architecture, then the
architecture is wrong.
>Another problem with OBV is the insane amount of complexity it has added
>to the protocols. Steve and I keep predicting that it will take years
>until the last few bugs are ironed out and different vendor implementations
>of OBV will interoperate reliably.
That is indeed a valid concern, as lack of interoperable implementations
will make the technology less useful.
As for garbage features: OBV provides a lot of concepts. Some may be useful,
and for others, only few will care about them (chunking and truncation come
to mind :), others might be useful, but still won't get implemented widely.
It is an unfortunate fact that standards always contain things which nobody
really needs...
Regards,
Martin
Michi Henning
> In article <Pine.HPX.4.05.100012...@bobo.ooc.com.au>,
> Michi Henning <mi...@ooc.com.au> wrote:
>
> >Consider: In the absence of value types, IDL is the *only* contract between
> >client and server. In all other respects, they care completely independent.
> >Yet, if they agree to use the same IDL, they can communicate, and all
> >of the transparencies of CORBA are preserved.
>
> I'm not sure whether this is a good argument against the OBV spec. For
> one thing, it is not a valid argument: There is always more contract
> between client and server but just IDL. These operations have a semantics
> behind them, which might be implicit from the operation names, or
> spelled-out in (typically) English text. So you not only have to know what
> the operations are, but also how to use them.
Sure, there are implicit semantics that client and server must agree on.
However, without OBV, there is *code* of any kind that they need to share.
OBV completely wrecks that.
Stephen Crawley
>> 11) Arrays are not really needed, when you have sequences.
>
>Yes and no. I guess the question is whether or not the added type safety is
>worth it. An array guarantees that *exactly* n things will be sent/received,
>whereas a bounded sequence only guarantees that *no more than* n things
>will be sent/received. Sometimes, the added type safety is appreciated.
>But it begs the question: is it really necessary to have arrays in the presence
>of sequences for a minor gain in type safety? Me feeling is that, in general,
>the answer is probably no. I'm saying that because arrays substantially add
>to the size of the code and the complexity of the APIs you have to use.
If we had a chance to redesign IDL from scratch, it would be nice to
replace both arrays and sequences with a more general constructor that
allowed you to specify both lower and upper bounds ... like UML and MOF.
-- Steve
Stephen Crawley
>
>> In article <Pine.HPX.4.05.100012...@bobo.ooc.com.au>,
>> Michi Henning <mi...@ooc.com.au> wrote:
>>
>> >client and server. In all other respects, they care completely independent.
>> >Yet, if they agree to use the same IDL, they can communicate, and all
>> >of the transparencies of CORBA are preserved.
>>
>> I'm not sure whether this is a good argument against the OBV spec. For
>> one thing, it is not a valid argument: There is always more contract
>> between client and server but just IDL. These operations have a semantics
>> behind them, which might be implicit from the operation names, or
>> spelled-out in (typically) English text. So you not only have to know what
>> the operations are, but also how to use them.
>
>Sure, there are implicit semantics that client and server must agree on.
>However, without OBV, there is *code* of any kind that they need to share.
>OBV completely wrecks that.
I think Michi means that there is NO *code* that the client(s) and server(s)
need to share.
Another way to say this is that classic IDL objects are ADTs with a
strong encapsulation boundary that can only be broken (deliberately)
if the client and server are colocated. With OBV valuetypes, ADT
encapsulation is easy to break accidentally or deliberately. All you
have to do is to implement an OBV method differently on the client and
server side.
-- Steve
Michi Henning
> >Sure, there are implicit semantics that client and server must agree on.
> >However, without OBV, there is *code* of any kind that they need to share.
> >OBV completely wrecks that.
>
> I think Michi means that there is NO *code* that the client(s) and server(s)
> need to share.
Right you are! ;-)
> Another way to say this is that classic IDL objects are ADTs with a
> strong encapsulation boundary that can only be broken (deliberately)
> if the client and server are colocated. With OBV valuetypes, ADT
> encapsulation is easy to break accidentally or deliberately. All you
> have to do is to implement an OBV method differently on the client and
> server side.
I hadn't thought of that but you are right, of course. But even assuming
that the implementations do the same thing everywhere, there is still the
question of how a provider of a service that uses OBVs can get the
code to an unknown number of clients written in an unknown number of languages
running on an unknown number of operatining systems and using an unknown
number of ORBs and ORB versions.
Basically, what it boils down to is that OBVs with operations are usable
only if you can control the deployment environments of both clients and
servers.
Michi Henning
> Michi Henning wrote:
> >
> > On Fri, 21 Jan 2000, Evan Ireland wrote:
> >
> > > The basic idea is that when generating proxies or skeletons for Java, C++ or
> > > other languages that support overloading, you strip off the suffix from the
> > > mangled name to get the Java or C++ name. For languages that don't support
> > > overloading, you don't strip off the suffix.
> >
> > Sure, I understand how this works. However, it doesn't remove the basic
> > problem, namely, that C and COBOL users still end up with very ugly APIs.
>
> I have three answers for this (the last two are not entirely serious):
>
> (1) It's not that ugly if the end-user chooses the mangling. The automatically
> generated mangled names from the Java to IDL mapping can be ugly though.
Sure. But where do you put the specification for what the mangled name
should look like? IDL isn't the right place, as I pointed out in a previous
posting. And, are we going to specify the names in a way that is independent
of the language mapping? If so, we'd better be careful -- some languages
don't permit underscores in identifiers, for example. The best place
would probably be an identifier mapping file as a secondary input to
the compiler. However, the rules and defaults for that mapping file would
have to be specified separately for each language, to take into account
each languages idiosynchracies.
> (2) C users can just switch to C++ if they want it to look nice.
Well, as you said, this isn't entirely serious, so why mention it?
> (3) COBOL is ugly anyway, so a few names with two underscores wouldn't matter.
Ditto. It is precisly that kind of arrogant attitude that really puts people
off. How would you like to be told that you are an old senile fossil who
still insists on programming in a dinosaur language like C++? How would
you like to be told the same thing in a few years time because you are
still programing in Java? The people who choose to write CORBA programs in
language X have, as a rule, pretty good reasons for chosing X. The last thing
they need to be told by some smart-alec is that they they are misguided
and that it's OK to run rough-shod over them because, after all, they
are "X users"... We are about to add a PL/1 mapping to CORBA, for good
reasons. Are you going to tell those people too that it's OK to serve
them a language mapping that makes it hard to keep down your breakfast?
> > Overloading is useful, no doubt. However, I don't see it as essential,
> > given the architectural goals of CORBA. The price you have to pay is too
> > high for languages that don't support overloading.
>
> The way we deal with it is:
>
> (1) Not using overloading in the services we provide and implement.
>
> (2) Allowing our customers to use it but informing them of the portability and
> usability consequences.
That's a naive way to look at it. Customers don't, as a rule, have the
sophistication of seeing the consequences of their own actions. And, even
when they do, it's no good giving them a feature that requires clairvoyance
to be used safely. Can you state for certain today that the IDL you just
wrote will never be have to be used from another programming language?
I can just see the people with egg on their faces: "Yes, we did this because
it was good for C++. Yes, we knew that it would look terrible in other
languages, but C++ is all we used for years, and there was nothing on
the horizon that would indicate a change." Enter Java...
> I think the fact that the Java to IDL standard mapping has actually defined a
> name mangling convention for CORBA,
The fact that Java to IDL defined a name mangling scheme doesn't make
that approach desirable (or good or sacrosanct). Some of the name mangling,
frankly, makes me gag. In addition, it's not perfect. Last time I looked,
there were a few cases where name clashes could not be resolved. You suggested
earlier that specifying the names to be used explicitly would be better
than mangled names. I agree, because that at least would result in something
that has half a chance of being human-readable. Unfortunately, the Java
to IDL mapping didn't use the approach you suggest -- despite the fact
that it would have been quite easy to use an identifier translation mapping
file that could have been fed as a secondary input to the compiler...
> it only makes sense to consider how that
> should be reflected in the language mappings (e.g. IDL to C++, IDL to Java)
> for languages that support overloading.
No. There is a *big* difference between going from Java to IDL (namely, from
the specific to the general) and going from IDL to Java (from the general
to the specific). Because there is only one general thing (IDL), but many
specific things (many languages), any approach that is chosen must be
suitable for all of the possible languages. That's a much harder problem
to solve than dealing with the issue for a single specific-to-general
transformation.
Jason Trenouth
I'm only skimming this thread but there are a couple of points about
overloading that I don't think have been aired.
(i) The existing bindings already have to deal with non-OO languages so not
doing overloading because these languages don't support it seems to be a
spurious argument. However, you could argue that they are burdened with faking
up enough OO stuff already so we should hold back on putting another straw on
their backs. :-j
(ii) Bindings to OO languages that _do_ support overloading may be _more_ of a
problem since IDL overloading may differ from the language overloading.
e.g. in Dylan, superclass ordering must be consistent so the following IDL
would be illegal when naively mapped into Dylan:
interface A {};
interface B {};
interface C : A, B {};
interface D : B, A {}; // (**)
interface E : C, D {}; // (*)
The last interface E, marked with (*), has inherited interfaces A and B in two
different orders via its directly inherited interfaces C and D.
To avoid this problem the IDL-Dylan mapping specifies the canonicalization of
the order of the inherited interfaces (alphabetically). In effect, this means
that interface D becomes:
interface D : A, B {};
You can see that this kind of thing could potentially break operation
overloading if it were to be added to IDL.
There may be similar issues in other OO languages.
__Jason
Bill Janssen
> IMO, the entire OBV thing was a very misguided attempt at making CORBA like
> Java, despite the fact that the architectural goals are very different.
Hear, hear!
> In particular, permitting operations on valuetypes has destroyed a
> fundamental architectural goal of CORBA, namely, that of implementation
> transparency.
Well, I'm less worried about that misfeature myself, though I agree it
will only work in very contricted circumstances.
> Consider: In the absence of value types, IDL is the *only* contract between
> client and server. In all other respects, they care completely independent.
> Yet, if they agree to use the same IDL, they can communicate, and all
> of the transparencies of CORBA are preserved.
Hmmm, that's a bit overstated. They can only communicate if they are
both share a common protocol or ORB, a fact that isn't part of the
IDL. Even then, there may be security restrictions to overcome, which
may not allow them to interoperate. Setting up the environment is
more complicated than just defining the IDL.
> Now, consider the consequences of this. IDL claims to be language,
> implementation, and OS transparent. Yet, we have a construct in IDL that
> breaks all of these transparencies. Imagine that one of the CORBAservices
> used valuetypes with operations, and that you are a vendor who wants to
> sell access to that that service. Without OBV, you just run the service
> somewhere and anyone can use it. With OBV with operations, you now have
> to ship client-side libraries for all possible combinations of programming
> language, compiler, compiler versions, operating system, ORB, and ORB version.
> That adds up to thousands of possible binary distributions real quick...
Sure, I can see that this might make a vendor sigh with regret at all
the extra work they have to do, but that doesn't mean that operations
on valuetypes are a bad idea.
> Another problem with OBV is the insane amount of complexity it has added
> to the protocols. Steve and I keep predicting that it will take years
> until the last few bugs are ironed out and different vendor implementations
> of OBV will interoperate reliably.
Yep. I think it's going to be worse than C++, if you can imagine it.
> It would have been so much simpler to add inheritance to structs. That would
> have given us much of the functionality of OBV without any of the baggage...
I guess it wouldn't have accomplished the key OBV goal of shoehorning
Java into CORBA, though.
Bill
--
Bill Janssen <jan...@parc.xerox.com> (650) 812-4763 FAX: (650) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
Bill Janssen
> I'm not trying to start a fight here, but I don't think that
> it would take longer to learn IDL if it used a syntax more obviously
> different from C++. After all, there are differences from C++ syntax
> (in, out, inout, const operations, boolean vs bool, module vs
> namespace, sequence vs list, tagged unions, ...) which you must keep
> in my mind when working with IDL.
But basing the syntax on C++ syntax probably reduced the resistance
people had to learning it -- it didn't seem like some foreign thing
that had to be mastered from scratch (regardless of what the actual
differences were). So it probably did help acceptance.
Evan Ireland
>
> Sure. But where do you put the specification for what the mangled name
> should look like? IDL isn't the right place, as I pointed out in a previous
> posting. And, are we going to specify the names in a way that is independent
> of the language mapping? If so, we'd better be careful -- some languages
> don't permit underscores in identifiers, for example. The best place
> would probably be an identifier mapping file as a secondary input to
> the compiler. However, the rules and defaults for that mapping file would
> have to be specified separately for each language, to take into account
> each languages idiosynchracies.
We take the view that if the user wants the mangled names to look pretty,
they should create the IDL with 'pretty' mangled names, on the assmuption
that two underscores in an operation name is not too bad-looking. Languages
that don't allow underscores in identifiers will have no more problems with
a double underscore than they have with the numerous IDL specifications
already in existence that make liberal use of underscores.
> > (2) C users can just switch to C++ if they want it to look nice.
>
> Well, as you said, this isn't entirely serious, so why mention it?
I must have been in a silly mood. I apologize for wasting the bandwidth.
> > (3) COBOL is ugly anyway, so a few names with two underscores wouldn't matter.
>
> Ditto. It is precisly that kind of arrogant attitude that really puts people
> off. How would you like to be told that you are an old senile fossil who
> still insists on programming in a dinosaur language like C++? How would
> you like to be told the same thing in a few years time because you are
> still programing in Java? The people who choose to write CORBA programs in
> language X have, as a rule, pretty good reasons for chosing X. The last thing
> they need to be told by some smart-alec is that they they are misguided
> and that it's OK to run rough-shod over them because, after all, they
> are "X users"... We are about to add a PL/1 mapping to CORBA, for good
> reasons. Are you going to tell those people too that it's OK to serve
> them a language mapping that makes it hard to keep down your breakfast?
That was an interesting interpretation of my statement! Anyway, you will
find that people frequently write IDL using conventions that are
appropriate to the 'main' language that they intend to use for client
and/or server development. Sometimes that means that the resulting code
appears foreign or 'ugly' in the environment in which it is used, for
example Java programmers might feel uncomfortable with the "my_method_name"
naming scheme that is frequently used in IDL specifications
(preferring "myMethodName").
The point is, CORBA is about interoperability, and in many cases that means
compromise. Nobody ever said that CORBA interoperability was pretty (or at
least if they did say it, I wouldn't agree).
And as far as COBOL programmers are concerned, I made no statement. The
COBOL language itself is obviously not going to be offended by my statement,
and I certainly won't be entering into a COBOL is ugly/pretty flame war.
> > > Overloading is useful, no doubt. However, I don't see it as essential,
> > > given the architectural goals of CORBA. The price you have to pay is too
> > > high for languages that don't support overloading.
> >
> > The way we deal with it is:
> >
> > (1) Not using overloading in the services we provide and implement.
> >
> > (2) Allowing our customers to use it but informing them of the portability and
> > usability consequences.
>
> That's a naive way to look at it. Customers don't, as a rule, have the
> sophistication of seeing the consequences of their own actions. And, even
> when they do, it's no good giving them a feature that requires clairvoyance
> to be used safely. Can you state for certain today that the IDL you just
> wrote will never be have to be used from another programming language?
I don't presume that any of my customers is unsophisticated! And I don't
make assumptions about the language mapping that will be used by customers.
Some of our customers use COBOL, some use ActiveX (IDispatch) which also
doesn't permit overloading.
I can state for certain today that anyone that has problems with the IDL
overloading scheme that we use ALREADY has problems with IDL, since IDL
permits underscores. And two underscores is only fractionally more ugly
than one underscore, and one underscore is used so frequently in IDL
speficifications that it becomes a non-issue, so long as the IDL writer
uses a reasonable suffix after their "__".
> I can just see the people with egg on their faces: "Yes, we did this because
> it was good for C++. Yes, we knew that it would look terrible in other
> languages, but C++ is all we used for years, and there was nothing on
> the horizon that would indicate a change." Enter Java...
>
> > I think the fact that the Java to IDL standard mapping has actually defined a
> > name mangling convention for CORBA,
>
> The fact that Java to IDL defined a name mangling scheme doesn't make
> that approach desirable (or good or sacrosanct). Some of the name mangling,
> frankly, makes me gag. In addition, it's not perfect. Last time I looked,
> there were a few cases where name clashes could not be resolved. You suggested
> earlier that specifying the names to be used explicitly would be better
> than mangled names. I agree, because that at least would result in something
> that has half a chance of being human-readable. Unfortunately, the Java
> to IDL mapping didn't use the approach you suggest -- despite the fact
> that it would have been quite easy to use an identifier translation mapping
> file that could have been fed as a secondary input to the compiler...
The principal reason we support overloading by name mangling is to allow
CORBA enabling of legacy 3-tier systems that ALREADY USE overloading. We
have a scheme that is simple to use, compatible with existing OMG
specifications, and allows customers to provide CORBA access to legacy
3-tier systems without a major rewrite.
> > it only makes sense to consider how that
> > should be reflected in the language mappings (e.g. IDL to C++, IDL to Java)
> > for languages that support overloading.
>
> No. There is a *big* difference between going from Java to IDL (namely, from
> the specific to the general) and going from IDL to Java (from the general
> to the specific). Because there is only one general thing (IDL), but many
> specific things (many languages), any approach that is chosen must be
> suitable for all of the possible languages. That's a much harder problem
> to solve than dealing with the issue for a single specific-to-general
> transformation.
I think the following approach is suitable for ALL languages that support an
IDL mapping.
(1) Mangled names "operation__suffix", where "suffix" is hand-generated or
automatically generated as determined by the user's development practices.
Any such IDL is already legal (no change to IDL is required).
(2) Any IDL mapping for a language that supports overloading should remove the
"__suffix" if that results in an unambiguous name.
(3) Any IDL mapping for a language that doesn't support overloading does not
require any change. Occasionally this will mean that users of these
languages have to deal with cumbersome names.
(4) Avoid use of overloaded names in specifications that are expected to be
widely adopted (e.g. CORBA services).
Personally, I never use this feature. But many of our customers do, and the
productivity they gain by it is in most cases going to far outweigh the
pain caused by unexpected requirements to support clients for which the
mapping of overloading is cumbersome.
Michi Henning
> The point is, CORBA is about interoperability, and in many cases that means
> compromise. Nobody ever said that CORBA interoperability was pretty (or at
> least if they did say it, I wouldn't agree).
Exactly. The compromise in this case is to not support overloaded operations.
> (1) Mangled names "operation__suffix", where "suffix" is hand-generated or
> automatically generated as determined by the user's development practices.
> Any such IDL is already legal (no change to IDL is required).
>
> (2) Any IDL mapping for a language that supports overloading should remove the
> "__suffix" if that results in an unambiguous name.
Under what circumstances could removing the suffix result in a ambiguous
name? How would I know?
> (3) Any IDL mapping for a language that doesn't support overloading does not
> require any change. Occasionally this will mean that users of these
> languages have to deal with cumbersome names.
>
> (4) Avoid use of overloaded names in specifications that are expected to be
> widely adopted (e.g. CORBA services).
You can't have it both ways. You want overloading, while admitting that
"this will mean that user of these languages have to deal with cumbersome
names" and that we should "avoid use of overloaded names in specifications
that are expected to be widely adopted (e.g. CORBA services)".
To paraphrase:
Well, it doesn't really work, it's not really language-independent,
and it really is a hack, so you shouldn't use it, except when
it doesn't matter.
Sorry, but that's not good enough for an international standard.
> Personally, I never use this feature. But many of our customers do, and the
> productivity they gain by it is in most cases going to far outweigh the
> pain caused by unexpected requirements to support clients for which the
> mapping of overloading is cumbersome.
You can put anything into your product you like. It may well be useful
for your customers. The fact that you have customers to whom the feature
is useful does not mean that it should be part of the CORBA spec.
Stephen Crawley
Jason Trenouth <ja...@harlequin.com> wrote:
>I'm only skimming this thread but there are a couple of points about
>overloading that I don't think have been aired.
>
>(i) The existing bindings already have to deal with non-OO languages so not
>doing overloading because these languages don't support it seems to be a
>spurious argument.
While it is true that many non-OO languages don't support overloading,
that is >>NOT<< the reason that IDL doesn't. The reasons ... often
repeated by Michi, Steve V, et al ... that overloading is not likely
to be added to IDL are:
1) in some (non-OO and other) languages, the mapping of overloading
would be too ugly, and
2) a change of this size would cause severe compatibility problems
for tens of thousands of users.
This is balanced by the fact that method overloading is essentially
a cosmetic feature that would add no new functionality to CORBA IDL.
-- Steve
Michi Henning
> > Consider: In the absence of value types, IDL is the *only* contract between
> > client and server. In all other respects, they care completely independent.
> > Yet, if they agree to use the same IDL, they can communicate, and all
> > of the transparencies of CORBA are preserved.
>
> Hmmm, that's a bit overstated. They can only communicate if they are
> both share a common protocol or ORB, a fact that isn't part of the
> IDL. Even then, there may be security restrictions to overcome, which
> may not allow them to interoperate. Setting up the environment is
> more complicated than just defining the IDL.
Bill, that's a red herring. You might as well say that it might not work
because the server has a power blackout or because it's behind a firewall.
The point is that it is understood that if I have connectivity and IIOP,
and I know the semantics of an interface, I can use that interface if
I have nothing but the IDL (yes, I know, I'll also need to get a reference
from somewhere, etc, etc...)
But the fundamental difference between normal IDL and IDL with OBVs is that,
if the OBVs contain operations, the client cannot talk to the server unless
it happens to have an implementation of the operations. There is no
defined (as part of the platform) for the client to obtain that code,
which fundamentally changes the coupling between client and server. In
particular, it goes from a very loose coupling (IDL only) to a very tight
coupling (object code that matches the client's OS, compiler, compiler,
version, language, ORB, and ORB version).
That is most definitely no longer implementation transparent. The
often advertised fact that a C++ client can transparently use a COBOL
server (and that I can replace the C++ client with a Java one any time
I like) no longer holds. That is a *big* architectural change.
> > That adds up to thousands of possible binary distributions real quick...
>
> Sure, I can see that this might make a vendor sigh with regret at all
> the extra work they have to do, but that doesn't mean that operations
> on valuetypes are a bad idea.
They are a bad idea in the context of the supposed language and implementation
transparency because OBVs with values are neither.
> > Another problem with OBV is the insane amount of complexity it has added
> > to the protocols. Steve and I keep predicting that it will take years
> > until the last few bugs are ironed out and different vendor implementations
> > of OBV will interoperate reliably.
>
> Yep. I think it's going to be worse than C++, if you can imagine it.
>
> > It would have been so much simpler to add inheritance to structs. That would
> > have given us much of the functionality of OBV without any of the baggage...
>
> I guess it wouldn't have accomplished the key OBV goal of shoehorning
> Java into CORBA, though.
Right. And that is the crux of the matter. CORBA had to become more like
Java, at any cost. Architectural integrity notwithstanding...
Cheers,
Evan Ireland
>
> On Tue, 25 Jan 2000, Evan Ireland wrote:
>
> > (2) Any IDL mapping for a language that supports overloading should remove the
> > "__suffix" if that results in an unambiguous name.
>
> name? How would I know?
An example is:
void myMethod(in boolean b);
void myMethod(in octet o);
Now for the C++ mapping since it is not guaranteed that the C++ mapped
equivalent of IDL boolean and octet types are distinct, one could
stipulate that the suffix should not be removed in this case. On the
other hand, I would much prefer to require the mapping of octet, char
and boolean be distinct, but I don't care enough about that to attempt
to make it happen.
> > (3) Any IDL mapping for a language that doesn't support overloading does not
> > require any change. Occasionally this will mean that users of these
> > languages have to deal with cumbersome names.
> >
> > (4) Avoid use of overloaded names in specifications that are expected to be
> > widely adopted (e.g. CORBA services).
>
> You can't have it both ways. You want overloading, while admitting that
> "this will mean that user of these languages have to deal with cumbersome
> names" and that we should "avoid use of overloaded names in specifications
> that are expected to be widely adopted (e.g. CORBA services)".
Of course you can have it both ways. You partition your IDL specifications
into two sets, (a) one for which you don't use mangled names, and (b) one
for which you do use them (or at least do consider using them). Many end
users who create (or reverse-engineer) their own IDL for internal systems
will be quite happy to use overloading. When designing external interfaces
for business-to-business interoperability, they could then insist that the
interfaces they are using for that purpose will be devoid of overloading.
> To paraphrase:
>
> Well, it doesn't really work, it's not really language-independent,
> and it really is a hack, so you shouldn't use it, except when
> it doesn't matter.
>
> Sorry, but that's not good enough for an international standard.
If you feel strongly about that I think that you will need to have
the Java to IDL language mapping specification revoked, since this
is not a convention that we invented, it is one we picked up from the
spec.
> > Personally, I never use this feature. But many of our customers do, and the
> > productivity they gain by it is in most cases going to far outweigh the
> > pain caused by unexpected requirements to support clients for which the
> > mapping of overloading is cumbersome.
>
> You can put anything into your product you like. It may well be useful
> for your customers. The fact that you have customers to whom the feature
> is useful does not mean that it should be part of the CORBA spec.
As I said, it already is a part of one the CORBA Java to IDL mapping spec. All
I am suggesting is that we consider extending a few mappings to reflect the
changes that have been made in the Java to IDL spec.
Please note that EJB / RMI / CORBA interoperability over IIOP relies on the
above mentioned handling of overloading (i.e. the name mangling part).
Michi Henning
> > > (2) Any IDL mapping for a language that supports overloading should remove the
> > > "__suffix" if that results in an unambiguous name.
> >
> > Under what circumstances could removing the suffix result in a ambiguous
> > name? How would I know?
>
> An example is:
>
> void myMethod(in boolean b);
> void myMethod(in octet o);
>
> Now for the C++ mapping since it is not guaranteed that the C++ mapped
> equivalent of IDL boolean and octet types are distinct, one could
> stipulate that the suffix should not be removed in this case. On the
> other hand, I would much prefer to require the mapping of octet, char
> and boolean be distinct, but I don't care enough about that to attempt
> to make it happen.
I see what you mean now. Hmmm... This is getting kind of tricky. I agree --
it would have been nice if the C++ mapping had been able to guarantee
that all IDL types are distinguishable for overloading. Alas, that wasn't
possible. In fact, I don't think it's even possible to guarantee that
integer types are distinguishable for overloading (the current words in
the spec notwithstanding). Consider a strange machine on which C++ short
and int are 16-bit words and long is a 64-bit word. (I doubt that
such a machine exists, so this is a bit hypothetical.) On this machine
the C++ mapping would have to map IDL short to C++ short or int, but would
have to map both IDL long and long long to C++ long. This would destroy
the distinguishability of built-in integer types for the purpose of
overloading.
[ This is really a theoretical aside but illustrates that, in the absence
of minimum size guarantees in standard C++, you can't guarantee that
IDL built-in integer types will be mapped to distinguishable C++ types. ]
Anyway, I'm not sure that having to remember such exceptions would
make life any easier for the programmer... In particular, what would
happen for languages with a weak typing notion? For example, in Perl, or
COBOL? Anything that overloads on any integer type would result in
mangled names. Heck, even for Java, overloading between unsigned and signed
integer types would result in mangled names.
While we are at it, another IDL gripe: unsigned integer types were most
likely a waste of time. To see why, read the excellent book "Large Scale
C++ Software Design", by John Lakos. He makes a very cogent argument for
why unsigned integers are a waste of time...
> Of course you can have it both ways. You partition your IDL specifications
> into two sets, (a) one for which you don't use mangled names, and (b) one
> for which you do use them (or at least do consider using them). Many end
> users who create (or reverse-engineer) their own IDL for internal systems
> will be quite happy to use overloading. When designing external interfaces
> for business-to-business interoperability, they could then insist that the
> interfaces they are using for that purpose will be devoid of overloading.
And today's internal interface is tomorrow's external one. I've been down
that path before...
> > To paraphrase:
> >
> > Well, it doesn't really work, it's not really language-independent,
> > and it really is a hack, so you shouldn't use it, except when
> > it doesn't matter.
> >
> > Sorry, but that's not good enough for an international standard.
>
> If you feel strongly about that I think that you will need to have
> the Java to IDL language mapping specification revoked, since this
> is not a convention that we invented, it is one we picked up from the
> spec.
I don't care much about the Java-to-IDL mapping, which is why I stayed
out of that process. Had I been involved, I don't think it would look
the way it does. At the very least, we would have a way to map mangled
names onto something more sensible. And, as I said before, Java to IDL
is a specific-to-general mapping, which is a lot easier than
finding a general set of features that can be reasonably mapped to a whole
pile of languages at once.
The fact that mapping Java-to-IDL mapping handles overloaded functions
by no means implies that IDL should have overloaded operations. And, let's
face it -- the Java-to-IDL mapping handles overloaded functions only because
Java already had them, not because of any innate need for the feature
in IDL.
> > You can put anything into your product you like. It may well be useful
> > for your customers. The fact that you have customers to whom the feature
> > is useful does not mean that it should be part of the CORBA spec.
>
> As I said, it already is a part of one the CORBA Java to IDL mapping spec. All
> I am suggesting is that we consider extending a few mappings to reflect the
> changes that have been made in the Java to IDL spec.
You are proposing a major change to IDL. That is a lot more sweeping than
the Java-to-IDL mapping. To get this change into the spec, you can try
to marshal support for an RFP. If you get the RFP approved, you can then
make a submission and try to have the submission accepted by both the
Platform Technology Committee and the Architecture Board. That is the
only way to get a change of this magnitude into the spec.
That's an awful lot of work for something that I can live without quite
easily. Overloaded operations would not provide an essential feature
for IDL, merely a convenience. And, if mangled names are not a problem,
as you keep assuring me, I suggest you write your IDL like this:
interface Foo {
void set__short__char(in short s, in char c);
void set__long__double(in long l, in double d);
void set__long__long__char__long(
in long l1,
in long l2,
in char c,
in long l3
);
void set__long__long__long__char(
in long l1,
in long l2,
in long l3,
in char c
);
};
After all, if double underscores and mangled names are acceptable for at
least some programming languages, then I don't see why they wouldn't be
acceptable in IDL.
Michi Henning
> I just wanted to point out to would-be C++ mapping implementors who are reading
> this that at least in C++, there is a way to deal with this without changing
> the language mapping. Even if you have:
>
> namespace CORBA
> {
> typedef Object* Object_ptr;
> }
>
> That doesn't mean that CORBA::Object::_nil() needs to be a null pointer. It can
> instead be a pointer to a CORBA::Object that throws a system exception when you
> try to invoke a method. In that way, you can be sure that clients cannot crash
> your server by sending nil object references as parameters to operations on
> your C++ servant objects. In this case I am assuming that accessing a NULL
> pointer causes a server crash whereas a CORBA system exception does not.
>
> The principal point is that user code in C++ servant classes doesn't need to
> check for null pointers for object reference parameters if this simple trick
> is used by the ORB implementor. This helps to create robust servers.
Yes and no. You could do something like that. However, that would require
instantiating at least one nil dummy proxy for every most-derived object
type in the client, so it would add some space overhead. (The space overhead
is probably tolerable though because clients will only ever deal with a quite
small number of object types for which they have stubs (a few hundred, at
most, and usually far fewer).
However, I would really prefer to see nil as a first-class concept in the
IDL type system because that would make it possible to catch a lot of
nil threats at compile time instead of at run-time. (Throwing an exception
on a nil access is not a lot better than a core dump because, either way,
the programmer has to take explicit action to deal with nil: either
explicitly test for it, or explicitly write a catch handler for it.)
> I was somewhat inclined to add to the list of gripes, since it was so good it
> looked as if it could have formed the basis for a new, improved CORBA!
Thanks. Unfortunately, I think it highly unlikely that these gripes will
ever be addressed.
> So here
> is my new gripe:
>
> <gripe>
>
> 'factory' is now a reserved IDL keyword. Combined with CORBA 2.3 section 3.2.4
> Keywords:
>
> Identifiers that collide with keywords (see Section 3.2.3, “Identifiers,”
> on page 3-6) are illegal. For example, “boolean” is a valid keyword;
> “Boolean” and “BOOLEAN” are illegal identifiers.
>
> I have no problem with the fact that IDL accomodates target languages that
> are case-insensitive. However the IDL syntax itself doesn't need to be so
> restrictive.
>
> I would suggest that the IDL specification could be changed so that 'Factory'
> is a legal identifier even when 'factory' is reserved, and that keywords
> should not clash with parameter and struct/union/valuetype field names.
>
> Without some such convention, every time new IDL keywords are added we end up
> with a whole bunch of IDL files that are no longer valid, except by the
> addition of leading underscores onto names in previously valid IDL files.
>
> Although this makes life harder for implementors who use cheap and dirty
> parser generators, it makes life easier for end users with existing (legacy)
> IDL.
There was a *huge* amount of discussion about the IDL keyword issue when
OBV was hammered out. The original spec required context-sensitive parsing,
claiming that it would be no problem to simply add new keywords without
making the corresponding identifiers illegal and then use a context-sensitive
parser to figure out whether a particular identifier is actually an
identifier or a keyword. That position was maintained until Steve found
a case that was completely undecipherable, context-sensitive parsing or not.
Steve and I went on an extended crusade to stop context-sensitive keywords
because context-sensitive parsing is evil (as we've known since the
PL/1 days). The leading underscore escape was eventually adopted as a
compromise because it was seen as a pragmatic solution to a problem that
occurs only rarely, and was non-intrusive to existing source code.
In hindsight, getting rid of this misfeature was a good thing indeed -- since
then, a number of other specs have added keywords to IDL. If we had allowed
context-sensitive keywords, we'd probably be in a complete parsing mess
by now...
If we were to allow "Factory" as an identifier that doesn't clash with the
"factory" keyword now, we'd unfortunately make life rather difficult in
terms of compatibility. For example, no CORBA 2.3 client could access a
server that used IDL with this new feature. Given that there are only a few
keywords in IDL (most of which have been there all along) and that keywords
aren't added on a weekly basis, the underscore escape mechanism was
probably the best compromise because it makes it possible to update
existing IDL that clashes with a new keyword with minimal fuss.
Evan Ireland
> After all, if double underscores and mangled names are acceptable for at
> least some programming languages, then I don't see why they wouldn't be
> acceptable in IDL.
I don't have any further points to make, so thanks for the lively discussion!
Evan Ireland
Ten excellent CORBA gripes, including:
> 5) The idea of a nil IOR value is misguided. It leads to the
> situation where the receiver of an IOR cannot ever risk using
> it without testing for nil first. Depending on the language
> mapping, not testing first is to risk a core dump.
> ...
I just wanted to point out to would-be C++ mapping implementors who are reading
this that at least in C++, there is a way to deal with this without changing
the language mapping. Even if you have:
namespace CORBA
{
typedef Object* Object_ptr;
}
That doesn't mean that CORBA::Object::_nil() needs to be a null pointer. It can
instead be a pointer to a CORBA::Object that throws a system exception when you
try to invoke a method. In that way, you can be sure that clients cannot crash
your server by sending nil object references as parameters to operations on
your C++ servant objects. In this case I am assuming that accessing a NULL
pointer causes a server crash whereas a CORBA system exception does not.
The principal point is that user code in C++ servant classes doesn't need to
check for null pointers for object reference parameters if this simple trick
is used by the ORB implementor. This helps to create robust servers.
I was somewhat inclined to add to the list of gripes, since it was so good it
looked as if it could have formed the basis for a new, improved CORBA! So here
is my new gripe:
<gripe>
'factory' is now a reserved IDL keyword. Combined with CORBA 2.3 section 3.2.4
Keywords:
Identifiers that collide with keywords (see Section 3.2.3, “Identifiers,”
on page 3-6) are illegal. For example, “boolean” is a valid keyword;
“Boolean” and “BOOLEAN” are illegal identifiers.
I have no problem with the fact that IDL accomodates target languages that
are case-insensitive. However the IDL syntax itself doesn't need to be so
restrictive.
I would suggest that the IDL specification could be changed so that 'Factory'
is a legal identifier even when 'factory' is reserved, and that keywords
should not clash with parameter and struct/union/valuetype field names.
Without some such convention, every time new IDL keywords are added we end up
with a whole bunch of IDL files that are no longer valid, except by the
addition of leading underscores onto names in previously valid IDL files.
Although this makes life harder for implementors who use cheap and dirty
parser generators, it makes life easier for end users with existing (legacy)
IDL.
</gripe>
Jonathan Biggar
> > Another way to say this is that classic IDL objects are ADTs with a
> > strong encapsulation boundary that can only be broken (deliberately)
> > if the client and server are colocated. With OBV valuetypes, ADT
> > encapsulation is easy to break accidentally or deliberately. All you
> > have to do is to implement an OBV method differently on the client and
> > server side.
>
> I hadn't thought of that but you are right, of course. But even assuming
> that the implementations do the same thing everywhere, there is still the
> question of how a provider of a service that uses OBVs can get the
> code to an unknown number of clients written in an unknown number of languages
> running on an unknown number of operatining systems and using an unknown
> number of ORBs and ORB versions.
>
> Basically, what it boils down to is that OBVs with operations are usable
> only if you can control the deployment environments of both clients and
> servers.
Michi, you are getting overly broad in your complaints about OBV. There
is a class of valuetypes that are immediately useful and valuable:
valueboxes and valuetypes with only public state members and no
operations. Since neither of these require any significant user written
code to operate properly, yet provide significant new semantics (nil and
referential identity), they do not have the problems that you are
complaining about. With these valuetypes, I have the ability to create
and transmit arbitrary graph-like data structures in their direct, most
useful form without having to rely on arbitrary flattening techniques
that complicate the issue.
Also, I believe that using valuetypes with operations can be successful
as long as the valuetype definer does one of two things:
1. Publish the source code for the valuetype operations (preferably in
multiple languages, but at least in clean portable code in one common
language) or
2. Document the behavior of the operations with at least the level of
rigor that is found in the C or C++ standard library documentation.
--
Jon Biggar
Floorboard Software
j...@floorboard.com
j...@biggar.org
Bill Janssen
Bill Janssen
> While we are at it, another IDL gripe: unsigned integer types were most
> likely a waste of time. To see why, read the excellent book "Large Scale
> C++ Software Design", by John Lakos. He makes a very cogent argument for
> why unsigned integers are a waste of time...
Yep, that's right. It makes much more sense to support value ranges
for fixed-point types (like integers).
The *lack* of unsigned integer types in concrete languages (like Java)
does however cause problems in hooking it up properly to all of these
pre-existing systems which *do* have unsigned integer types... Sigh.
Evan Ireland
>
> ... (stuff from Michi Henning deleted)
>
> Michi, you are getting overly broad in your complaints about OBV. There
> is a class of valuetypes that are immediately useful and valuable:
> valueboxes and valuetypes with only public state members and no
> operations. Since neither of these require any significant user written
> code to operate properly, yet provide significant new semantics (nil and
> referential identity), they do not have the problems that you are
> complaining about. With these valuetypes, I have the ability to create
> and transmit arbitrary graph-like data structures in their direct, most
> useful form without having to rely on arbitrary flattening techniques
> that complicate the issue.
I would agree that valuetypes without operations are a useful addition.
But I think that is about where the usefulness ends.
> Also, I believe that using valuetypes with operations can be successful
> as long as the valuetype definer does one of two things:
>
> 1. Publish the source code for the valuetype operations (preferably in
> multiple languages, but at least in clean portable code in one common
> language) or
I have to side with Michi when it comes to operations on valuetypes.
Perhaps you would care to estimate the amount of time it would take to develop
a C++ equivalent for the valuetype that is generated from applying the Java to
IDL mapping to "java.util.List", for the purpose of being able to write a C++
client that can call a finder method that returns a collection of object
references on the home interface of an EJB entity bean (using IIOP as defined
by the EJB / CORBA interoperability document).
Perhaps someone can create a grad student project to do the C++ implementation
for the java::util::List valuetype so that a C++ client using IIOP can
interoperate with an EJB component using the following EJB home interface
(AccountHome)
interface Account : javax::ejb::EJBObject
{
double getBalance();
};
interface AccountHome : javax::ejb::EJBHome
{
Account findByPrimaryKey(in CORBA::WStringValue key);
java::util::List findAllAccounts();
};
The project of course would be to develop a portable C++ client that
can retrieve the total of all account balances (never mind the rounding
errors that result from using 'double' for storing money values).
I don't expect that this project will be finished quickly. The point
of the project of course would be to determine exactly how hard it really
is. If we are really lucky, perhaps somebody has already done this and
can report on how many person-months it took.
The java::util::List and java::util::Collection valuetypes must be the
most important as far as 'textbook' current interoperability between
CORBA and EJB is concerned. If the porting of the operations on these
valuetypes does not prove to be easy, it does not fare well for
valuetypes with operations in general.
As soon as you allow people to use valuetypes with operations (and especially
in the case of Java), you end up with an interoperability nightmare. The sooner
folks realize this, the better off we'll all be.
> 2. Document the behavior of the operations with at least the level of
> rigor that is found in the C or C++ standard library documentation.
That's all very well, but item (1) above is the main sticking point.
________________________________________________________________________________
Michi Henning
> Jonathan Biggar wrote:
> >
> > ... (stuff from Michi Henning deleted)
> >
> > Michi, you are getting overly broad in your complaints about OBV. There
> > is a class of valuetypes that are immediately useful and valuable:
> > valueboxes and valuetypes with only public state members and no
> > operations. Since neither of these require any significant user written
> > code to operate properly, yet provide significant new semantics (nil and
> > referential identity), they do not have the problems that you are
> > complaining about. With these valuetypes, I have the ability to create
> > and transmit arbitrary graph-like data structures in their direct, most
> > useful form without having to rely on arbitrary flattening techniques
> > that complicate the issue.
Absolutely. So why didn't we stop there? Why did we have to have all the
other baggage?
> I would agree that valuetypes without operations are a useful addition.
> But I think that is about where the usefulness ends.
Exactly.
> > Also, I believe that using valuetypes with operations can be successful
> > as long as the valuetype definer does one of two things:
> >
> > 1. Publish the source code for the valuetype operations (preferably in
> > multiple languages, but at least in clean portable code in one common
> > language) or
>
> I have to side with Michi when it comes to operations on valuetypes.
Hey Evan, we agree on something! ;-)
I'm using CORBA precisely so that I *don't* have to publish the bloody source
code for every possible language, compiler, OS, and ORB under the sun.
> The java::util::List and java::util::Collection valuetypes must be the
> most important as far as 'textbook' current interoperability between
> CORBA and EJB is concerned. If the porting of the operations on these
> valuetypes does not prove to be easy, it does not fare well for
> valuetypes with operations in general.
That's an interesting argument. I don't know enough about the implementation
of these types to comment on the complexity of implementation. However,
I agree that this sort of thing is likely to be a problem in general.
Evan Ireland
>
> Evan, what's the OMG IDL for this interface?
I think it looks like this:
module java
{
module util
{
valuetype List
{
// methods are optional according to mapping spec
// there is no data because java.util.List is an interface
};
};
};
So basically java.util.List and java.util.Collection map to empty valuetypes,
or valuetypes with methods and no data.
I can't see how a C++ client can ever use that!
Jonathan Biggar
> > Also, I believe that using valuetypes with operations can be successful
> > as long as the valuetype definer does one of two things:
> >
> > 1. Publish the source code for the valuetype operations (preferably in
> > multiple languages, but at least in clean portable code in one common
> > language) or
>
> I have to side with Michi when it comes to operations on valuetypes.
>
> a C++ equivalent for the valuetype that is generated from applying the Java to
> IDL mapping to "java.util.List", for the purpose of being able to write a C++
> client that can call a finder method that returns a collection of object
> references on the home interface of an EJB entity bean (using IIOP as defined
> by the EJB / CORBA interoperability document).
>
> Perhaps someone can create a grad student project to do the C++ implementation
> for the java::util::List valuetype so that a C++ client using IIOP can
> interoperate with an EJB component using the following EJB home interface
> (AccountHome)
>
> interface Account : javax::ejb::EJBObject
> {
> double getBalance();
> };
>
> interface AccountHome : javax::ejb::EJBHome
> {
> Account findByPrimaryKey(in CORBA::WStringValue key);
> java::util::List findAllAccounts();
> };
Well, just pick the worst possible example and throw it in my face. :-)
I see this more as a symptom of brokenness in the Java-IDL mapping.
I still believe there is a class of valuetypes with operations that is
useful. As an example for discussion, try this:
abstract valuetype Point {
double x_coord();
double y_coord();
double radius();
double angle();
};
valuetype XYPoint : Point {
private double x;
private double y;
};
valuetype RAPoint : Point {
private double r;
private double a;
};
Here is a nice little ADT that gets you cartesian/polar coordinates &
conversions.
The implementation of the operations is obvious and simple, and that is
the key. As long as the valuetype designer designs compact valuetypes
with simple and obvious operation implementations, I don't think the use
of those valuetypes will cause significant troubles.
On the contrary, object component models like EJB tend to be very
complex under the covers. This is not a good use of valuetypes, since
the valuetype operations are easily to complex to provide a portable
implementation or document in a way that non-experts can expect to
implement them.
Joachim Achtzehnter
>
> There is a class of valuetypes that are immediately useful and
> valuable: valueboxes and valuetypes with only public state members
> create and transmit arbitrary graph-like data structures in their
> direct, most useful form without having to rely on arbitrary
> flattening techniques that complicate the issue.
Exactly. This essentially fixes the shortcomings of IDL struct and
friends, and was dearly missed by many CORBA systems dealing with
complex data. Two comments though:
1. From the point of view of 'good language design', would it then not
have been better to fix struct and friends instead of adding a
new valuetype mechanism?
2. Valuetypes were added by an RFP process with the name 'Objects by
Value'. :-)
Independent of the question whether support for passing objects (with
operations) by value makes sense for CORBA, I would have preferred if
the two issues (fixing structs and OBV) would have been addressed
separately. The way it was done resulted in this hugely complex mess
we have now.
Joachim
--
joa...@kraut.bc.ca (http://www.kraut.bc.ca)
joa...@mercury.bc.ca (http://www.mercury.bc.ca)
Martin v.Loewis
Evan Ireland <eire...@sybase.com> wrote:
>So basically java.util.List and java.util.Collection map to empty valuetypes,
>or valuetypes with methods and no data.
>
>I can't see how a C++ client can ever use that!
If that all there is, a Java client cannot use that either. GIOP clearly
defines how an empty value type is transmitted: essentially as an empty
octet string (plus some type information).
I think there is a piece missing: The actual thing returned won't be
just a List, but a LinkedList, or a Vector, or the like. I know nothing
about java2idl, but I guess you'd need valuetypes for the concrete
realizations of the List interface. Are you sure List maps to a valuetype,
and not to an abstract valuetype?
Consider a specific implementaiton of List, e.g. Vector. AFAICT, it maps
to
valuetype Vector{
private long capacityIncrement;
private long elementCount;
private sequence<java::lang::Object> elementData;
};
I think it is perfectly clear how to access this in C++, provided you know
what java::lang::Object is.
It looks like a client of java2idl must be aware of the complete Java type
system. Somehow, this does not surprise me at all.
Regards,
Martin
Martin v.Loewis
Joachim Achtzehnter <joa...@kraut.bc.ca> wrote:
>Independent of the question whether support for passing objects (with
>operations) by value makes sense for CORBA, I would have preferred if
>the two issues (fixing structs and OBV) would have been addressed
>separately. The way it was done resulted in this hugely complex mess
>we have now.
In the way the OMG works, the only way to make sure something comes out
as you desire is to participate in the process yourself (and even that
is not necessarily a guarantee :-)
I personally think the solution to 'objects by value' is satisfying.
I find that the question you've not asked should be answered as 'it
makes no sense'. People who had asked really did not want to get
objects-by-value, they wanted valuetypes all along...
Regards,
Martin