PROPOSAL: Objective-C++
Ziemowit Laski
As some of you may know, Apple is currently using a customized
gcc 2.95.2 as its system compiler for Mac OS X. One of the
Apple additions to its gcc 2.95.2 is a front-end for the
Objective-C++ language (cc1objplus).
The Objective-C++ language may be thought of an extension of C++,
analogously to how Objective-C extends C. The language was
originally envisioned as an interface technology, enabling users
to directly invoke Objective-C APIs (such as NeXTStep/GNUStep, or
Cocoa on Mac OS X) from C++ code -- and vice versa -- without the
need for C glue code. Needless to say, Objective-C++ is extremely
useful in this regard, allowing developers to port applications
to Mac OS X (and other platforms with existing Objective-C
frameworks) with much more ease.
To the seasoned programmer :), Objective-C++ provides an opportunity
to leverage the characteristics of both C++ and Objective-C in the
same translation unit. The C++ and Objective-C object models
complement each other quite nicely, allowing programmers to make
trade-offs between efficiency and type-safety on the one hand, and
flexibility and dynamism on the other.
Unfortunately, even though it may be of interest to the outside
community (e.g., GNUStep users), the existing 2.95.2 version of
Objective-C++ is not really in a state amenable to integration into
FSF 2.95.x sources. But . . .
We are currently working on rolling out gcc 3.x on Mac OS X.
Obviously, this work will include bringing up the Objective-C++
3.x front-end. This time around, however, we would like to
coordinate its development with the community at large, so
that the finished (or even evolving) product can become part
of the FSF tree. Obviously, we will strive to integrate
Objective-C++ into the FSF tree in such a way that it will
have minimal impact on those _not_ wishing to use it. :)
The purpose of this post is twofold. First, we'd like
to know whether there exists an interest in the community
for incorporating Objective-C++ capability into FSF gcc 3.x.
Second, if there _is_ interest, we would like to request
permission to make one small change to the C++ build
process _right now_ that would make everyone's life
easier from then on. The idea is to change gcc/cp/parse.y
to gcc/cp/cp-parse.in, and then use sed to separate out
the C++ and Objective-C++ portions of the Yacc file,
_exactly_ as is presently being done with C and Objective-C.
The good news about adding Objective-C++ to gcc is that
very little actual new code will be required! Most of the
functionality already exists in the cp/ and objc/ folders. :)
Thanks for reading this. We look forward to hearing from all
of you.
--Zem
--------------------------------------------------------------
Ziemowit Laski Apple Computer, Inc.
zla...@apple.com 2 Infinite Loop, MS 302-4SN
+1.408.974.6229 Fax .1344 Cupertino, CA 95014-2085
cbbr...@acm.org
> The purpose of this post is twofold. First, we'd like
> to know whether there exists an interest in the community
> for incorporating Objective-C++ capability into FSF gcc 3.x.
One suggestion: You might want to make sure you "cc:" this to some of
the folks at Cygnus/Red Hat, as well as to the official GCC compiler
team. (See <http://gcc.gnu.org/>.)
While it's nice (actually _very nice_) to see an attempt for Apple to
be participative in things, it's likely to be a whole lot more useful
to contact the Official Folks that actually decide what's going to be
in Official GCC Releases.
--
(concatenate 'string "cbbrowne" "@acm.org")
http://www.cbbrowne.com/info/xwindows.html
Atheism is a non-prophet organization.
Stan Shebs
>
> PUTTING OBJECTIVE-C++ INTO GCC 3.x
Probably not a tough inference :-), but in case there's any doubt,
I support doing this.
> The Objective-C++ language may be thought of an extension of C++,
> analogously to how Objective-C extends C. The language was
> originally envisioned as an interface technology, enabling users
> to directly invoke Objective-C APIs (such as NeXTStep/GNUStep, or
> Cocoa on Mac OS X) from C++ code -- and vice versa -- without the
> need for C glue code. Needless to say, Objective-C++ is extremely
> useful in this regard, allowing developers to port applications
> to Mac OS X (and other platforms with existing Objective-C
> frameworks) with much more ease.
In fact, when I originally heard about Objective-C++, I thought
"geez, another one of those strange Apple ideas". However,
without it, developers with bodies of Objective-C and C++ code
to integrate have to write and maintain literally hundreds of
shims written in the common subset of C. While there are some
automated interface generation systems out there, there's nothing
standard and in practice they haven't been that easy to use.
If anybody is wondering about the object models, the best way
to describe them is as "mutually oblivious". In a sense, the
ObjC and C++ models are interacting only via C-level machinery,
but it's being handled by the compiler, and thus more efficient
all around.
> The good news about adding Objective-C++ to gcc is that
> very little actual new code will be required! Most of the
> functionality already exists in the cp/ and objc/ folders. :)
Ironically, if the long-term goal of integrating all the C
dialect frontends had been achieved, this would be trivial.
Hey, let's blame Tiemann for making cc1plus be a separate program
instead of a runtime option to cc1... :-)
Stan
Ovidiu Predescu
people have been asking NeXT/Apple for many years to donate the
Objective-C++ front-end to GCC. I'm glad this will eventually happen.
I definitely support this!
Regards,
--
Ovidiu Predescu <ovi...@cup.hp.com>
http://orion.rgv.hp.com/ (inside HP's firewall only)
http://sourceforge.net/users/ovidiu/ (my SourceForge page)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
On Tue, 13 Nov 2001 12:47:00 -0800, Ziemowit Laski <zla...@apple.com> wrote:
> PUTTING OBJECTIVE-C++ INTO GCC 3.x
>
> As some of you may know, Apple is currently using a customized
> gcc 2.95.2 as its system compiler for Mac OS X. One of the
> Apple additions to its gcc 2.95.2 is a front-end for the
> Objective-C++ language (cc1objplus).
>
> The Objective-C++ language may be thought of an extension of C++,
> analogously to how Objective-C extends C. The language was
> originally envisioned as an interface technology, enabling users
> to directly invoke Objective-C APIs (such as NeXTStep/GNUStep, or
> Cocoa on Mac OS X) from C++ code -- and vice versa -- without the
> need for C glue code. Needless to say, Objective-C++ is extremely
> useful in this regard, allowing developers to port applications
> to Mac OS X (and other platforms with existing Objective-C
> frameworks) with much more ease.
>
> To the seasoned programmer :), Objective-C++ provides an opportunity
> to leverage the characteristics of both C++ and Objective-C in the
> same translation unit. The C++ and Objective-C object models
> complement each other quite nicely, allowing programmers to make
> trade-offs between efficiency and type-safety on the one hand, and
> flexibility and dynamism on the other.
>
> Unfortunately, even though it may be of interest to the outside
> community (e.g., GNUStep users), the existing 2.95.2 version of
> Objective-C++ is not really in a state amenable to integration into
> FSF 2.95.x sources. But . . .
>
> We are currently working on rolling out gcc 3.x on Mac OS X.
> Obviously, this work will include bringing up the Objective-C++
> 3.x front-end. This time around, however, we would like to
> coordinate its development with the community at large, so
> that the finished (or even evolving) product can become part
> of the FSF tree. Obviously, we will strive to integrate
> Objective-C++ into the FSF tree in such a way that it will
> have minimal impact on those _not_ wishing to use it. :)
>
> The purpose of this post is twofold. First, we'd like
> to know whether there exists an interest in the community
> for incorporating Objective-C++ capability into FSF gcc 3.x.
>
> Second, if there _is_ interest, we would like to request
> permission to make one small change to the C++ build
> process _right now_ that would make everyone's life
> easier from then on. The idea is to change gcc/cp/parse.y
> to gcc/cp/cp-parse.in, and then use sed to separate out
> the C++ and Objective-C++ portions of the Yacc file,
> _exactly_ as is presently being done with C and Objective-C.
>
> The good news about adding Objective-C++ to gcc is that
> very little actual new code will be required! Most of the
> functionality already exists in the cp/ and objc/ folders. :)
>
Martin Brecher
that sounds great. C++ is a defacto standard for a lot of developers and
most programming friends I know are using mostly or only C++. ObjC++
could bring the force of those ones to the NeXT world; thus resulting in
more apps for OS X and GNUstep. Additionally, a lot of current programs
may be easily ported to our beloved OpenStep platforms.
Also I guess that this effort will be seen positively by a lot of
companies as it is a very supportive step in their direction and a proof
of the cross platform attitude of the OpenStep community.
Greetings,
Martin Brecher
Ziemowit Laski wrote:
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep
>
>
Tom White
> The purpose of this post is twofold. First, we'd like
> to know whether there exists an interest in the community
> for incorporating Objective-C++ capability into FSF gcc 3.x.
I would love to see this happen, so count me in as very interested.
> Second, if there _is_ interest, we would like to request
> permission to make one small change to the C++ build
> process _right now_ that would make everyone's life
> easier from then on. The idea is to change gcc/cp/parse.y
> to gcc/cp/cp-parse.in, and then use sed to separate out
> the C++ and Objective-C++ portions of the Yacc file,
> _exactly_ as is presently being done with C and Objective-C.
Hopefully this can be changed soon.
> The good news about adding Objective-C++ to gcc is that
> very little actual new code will be required! Most of the
> functionality already exists in the cp/ and objc/ folders. :)
This is good news, I had thought that the reason objc++ had not
made it back into gcc was because apple had to use a special
LL(k) parser. An objc++ compiler will greatly ease the migration
path for gnustep developers and allow objc users to easily
use existing c++ libraries. Hopefully the gcc people will also be
excited about adding in this valuable contribution from apple.
Cheers,
-Tom
--
===========================================================
Tom White t...@media.mit.edu
===========================================================
Frederic
>
> PUTTING OBJECTIVE-C++ INTO GCC 3.x
> The purpose of this post is twofold. First, we'd like
> to know whether there exists an interest in the community
> for incorporating Objective-C++ capability into FSF gcc 3.x.
Hello,
This is definitively something I would like to see happen. There are a
lot of C++ libraries available and it would be a great advantage for
Objectvie-C to be able to use them. There are also a lot of legacy C++
apps that could be made native to MacOS-X/Cocoa and GNUstep.
Regards, Frédéric
Markus Grabert
> PUTTING OBJECTIVE-C++ INTO GCC 3.x
[...]
> We are currently working on rolling out gcc 3.x on Mac OS X.
> Obviously, this work will include bringing up the Objective-C++
> 3.x front-end. This time around, however, we would like to
> coordinate its development with the community at large, so
> that the finished (or even evolving) product can become part
> of the FSF tree. Obviously, we will strive to integrate
> Objective-C++ into the FSF tree in such a way that it will
> have minimal impact on those _not_ wishing to use it. :)
>
> The purpose of this post is twofold. First, we'd like
> to know whether there exists an interest in the community
> for incorporating Objective-C++ capability into FSF gcc 3.x.
LOL.
People were waiting for *YEARS* for this ...
.. and YOU are asking whether there exists an interest ...
> The good news about adding Objective-C++ to gcc is that
> very little actual new code will be required! Most of the
> functionality already exists in the cp/ and objc/ folders. :)
>
> Thanks for reading this. We look forward to hearing from all
> of you.
/troll mode on
Nice try.
Well, of course I like a ObjC++, but what I REALLY want to see is
- ANSI Objective-C, with a full definition of the runtime; and
therefore one standard way to combine ObjC with other languages.
- a common (or at least fully compatible) objc runtime of GNU's gcc
and Apple's cc.
- OpenStep API alive and kicking (=used) for MANY more years,
even if this means new versions of OpenStep (well, I don't know much
to improve, but other people might have some ideas).
Well, perhaps I'm fanatic and a troll, but I think if Apple wants to go
the OpenSource way, there should be a way to combine the ressources of
the GNUstep world and MacOS X and their community, since this is the only
way to establish the best development framework: OpenStep.
IMHO one reason why Objective-C is not popular (I'm not talking about
OpenStep) is that there are just 3 maintained compilers AFAIK, each using
a different (or no) runtime and their own extentions.
And just because there is no ISO-ObjectiveC or similar standard. I think
it is nearly too late to establish an ISO-ObjectiveC, this should have
been done years ago.
If there is a standard, people will more likely use it and therefore will
be more compilers for that standard.
Well, if it is no standardized programming language, why should people use
an API that uses this proprietary programming language ?
I don't this this is the only reason why OpenStep or GNUstep is so
unpopular. I don't even think it is the most important one. But at least
it was an important one for the last years.
I think Objective-C++ will at least make it easier to evangelize people
to use ObjectiveC and/or the OpenStep API.
C++ is common and if you can convince developers that they still can
develop (sort of) C++ programms, they're willing to give it a try.
PS: I had a very bad week, so sorry for any insults.
/troll mode off
.. and yes, I'm very interested ;)
greetings max
Richard Frith-Macdonald
On Tuesday, November 13, 2001, at 08:47 PM, Ziemowit Laski wrote:
> PUTTING OBJECTIVE-C++ INTO GCC 3.x
Of course we want it ... a way to link legacy C++ code in to modern ObjC
apps!
Richard Frith-Macdonald
On Thursday, November 15, 2001, at 04:13 PM, Richard Frith-Macdonald
wrote:
PS. only vaguely related (as a compiler related issue) .. what are the
chances of
getting the ObjC runtime donated to the FSF? It would be nice to merge
the two runtimes.
David Relson
>On Thursday, November 15, 2001, at 04:13 PM, Richard Frith-Macdonald wrote:
>
>>
>PS. only vaguely related (as a compiler related issue) .. what are the
>chances of
>getting the ObjC runtime donated to the FSF? It would be nice to merge
>the two runtimes.
Now that gdb 5.1 is about to be released, I am reminded that Objective-C is
supported only by patching the source code and rebuilding gdb. Every major
release of gdb not only breaks the previous patches, but makes the
integration of Objective-C support even harder. It'd be really nice to
have Objective-C support integrated in the released version!
David
Stan Shebs
>
> [...] what are the chances of
> getting the ObjC runtime donated to the FSF? It would be nice to merge
> the two runtimes.
Speaking as the likely worker were the runtime to be donated, I
can say "the FSF is not very enthusiastic". :-) Apple's sources
are available as part of Darwin should anybody wish to look for
themselves, but basically our ObjC runtime is rife with assembly
code and NeXT/Mach-isms. Also, I don't think anybody actually
knows whether GNU libobjc is better or worse than objc4 - if
for instance libobjc turned out to offer better performance, I
think you might see Apple suddenly abandon objc4...
So yeah, I agree that the two runtimes ought to be merged, but I
don't yet know the best approach to take.
Stan
Stan Shebs
>
> - ANSI Objective-C, with a full definition of the runtime; and
> therefore one standard way to combine ObjC with other languages.
Creating an ANSI standard is a lengthy and expensive process, and
nobody who cares about ObjC has deep enough pockets to make it
happen. That doesn't preclude having a formal quasi-standard,
and if I weren't helping get GCC 3 to where it can be the default
compiler for OS X, that would probably be one of the things I'd be
working on.
Stan
Erik M. Buck
If Apple ever donated their Objective-C run-time to the FSF (presumably
under GPL or LGPL), they would probably have to stop using it themselves :(
There are more ways to support open source than the FSF and most are more
politically and legally viable. I personally like the BSD style licenses.
Stan Shebs
>
> Apple's Objective-C run-time is already open-source as part of Darwin.
> If Apple ever donated their Objective-C run-time to the FSF (presumably
> under GPL or LGPL), they would probably have to stop using it themselves :(
Not an issue. libobjc has one of those "special exceptions" to
allow its use in non-GPL programs, and a donated objc4 would have
a similar provision. Take a look at the top of any libobjc source
file to see how it reads.
Stan
Alexandre Oliva
Besides, whenever you assign copyright of your code to the FSF, the
FSF grants you back the rights to do pretty much anything you could do
with the code before donating it.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
Ovidiu Predescu
> >IMO when we talk about standardizing Objective-C, we talk about the
> >runtime system and the language itself. Fortunately the language is
> >pretty much similar across compilers, as the most widely used compiler
> >is the GNU compiler. It may be a problem with the POC compiler of
> >David Stes, we need to talk to him about that.
>
> David Stes, isn't that the guy that hates any NS*-ism concerning
> Objective-C? I remember one thread in comp.lang.objective-c, where David
> Stes was ranting about Apple not using Object but NSObject as the root
> class of their Objcetive-C implementation.
I don't want to defend David Stes here, but as an Objective-C compiler
developer I think he ought to represent his ideas in such a
discussion. There are many neat things in POC that are quite
interesting, like blocks for example. I'm sure some of these ideas
would benefit the GNU compiler implementation in the long run. I think
David's hate of NS*-ism is irrelevant here, as we are talking about
the language and the runtime system.
Regards,
--
Ovidiu Predescu <ovi...@cup.hp.com>
http://orion.nsr.hp.com/ (inside HP's firewall only)
Joe Buck
"Erik M. Buck" wrote:
> >> Apple's Objective-C run-time is already open-source as part of Darwin.
> >> If Apple ever donated their Objective-C run-time to the FSF (presumably
> >> under GPL or LGPL), they would probably have to stop using it themselves:
Stan Shebs wrote:
> > Not an issue. libobjc has one of those "special exceptions" to
> > allow its use in non-GPL programs, and a donated objc4 would have
> > a similar provision. Take a look at the top of any libobjc source
> > file to see how it reads.
Alexandre Oliva wrote:
> Besides, whenever you assign copyright of your code to the FSF, the
> FSF grants you back the rights to do pretty much anything you could do
> with the code before donating it.
But this grant-back isn't transferable to customers, so without explicit
permission in the license Apple couldn't give their customers permission
to do something that the license forbids. Still, it's moot, the donated
library would need to have the special exception.
de...@gnat.com
permission in the license Apple couldn't give their customers permission
to do something that the license forbids. Still, it's moot, the donated
library would need to have the special exception.
>>
Sure it is! Apple could provide a separate license that allows anyone to do
anything they like. The "pretty much anything" certainly includes the
capability of issuing versions with different licenses.
Joe Buck
We could argue the point, but it isn't relevant, as it would be an
argument over an unlikely hypothetical (that the FSF would insist
on a license that wouldn't be suitable).
Kim Shrier
> I think
> David's hate of NS*-ism is irrelevant here, as we are talking about
> the language and the runtime system.
>
About a year ago, I was about 50% through adding support for protocols
to the POC. David Stes raised such an objection to it that I stopped
work. This is one of the NS*-ism's that David dislikes and it looks
to me like it would have a direct influence on the language and the
runtime system.
> There are many neat things in POC that are quite
> interesting, like blocks for example.
I agree. I would like to see blocks in the GNU Objective C compiler.
Kim
--
Kim Shrier - principal, Shrier and Deihl - mailto:k...@tinker.com
Remote Unix Network Admin, Security, Internet Software Development
Tinker Internet Services - Superior FreeBSD-based Web Hosting
http://www.tinker.com/
Stan Shebs
>
> On Fri, 16 Nov 2001 16:04:26 +0100, LHel...@kabel.de wrote:
>
> > >IMO when we talk about standardizing Objective-C, we talk about the
> > >runtime system and the language itself. Fortunately the language is
> > >pretty much similar across compilers, as the most widely used compiler
> > >is the GNU compiler. It may be a problem with the POC compiler of
> > >David Stes, we need to talk to him about that.
> >
> > David Stes, isn't that the guy that hates any NS*-ism concerning
> > Objective-C? I remember one thread in comp.lang.objective-c, where David
> > Stes was ranting about Apple not using Object but NSObject as the root
> > class of their Objcetive-C implementation.
>
> I don't want to defend David Stes here, but as an Objective-C compiler
> developer I think he ought to represent his ideas in such a
> discussion. There are many neat things in POC that are quite
> interesting, like blocks for example. I'm sure some of these ideas
> would benefit the GNU compiler implementation in the long run. I think
> David's hate of NS*-ism is irrelevant here, as we are talking about
> the language and the runtime system.
Some months ago on comp.lang.objective-c I invited him to participate
in FSF GCC development, independently of Apple's participation, but
he didn't respond. The invitation is still open, there's nothing to
keep him from working with the FSF.
Stan
Ziemowit Laski
On Monday, November 19, 2001, at 11:43 , Kim Shrier wrote:
>> There are many neat things in POC that are quite
>> interesting, like blocks for example.
>
> I agree. I would like to see blocks in the GNU Objective C compiler.
Two questions on behalf of the benighted among us (which may include just
me, but so be it):
-- What does POC stand for?
-- What is this 'blocks' feature in the POC compiler?
Thanks!
Kim Shrier
>
>
> Two questions on behalf of the benighted among us (which may include just
> me, but so be it):
> -- What does POC stand for?
Portable Object Compiler
> -- What is this 'blocks' feature in the POC compiler?
>
A block is a piece of code that can be passed as a parameter in a
subroutine or a method. Smalltalk has this feature and it is
similar to Lambda expresions in Lisp. The classic example of the
usefulness of blocks is in sorting routines. For example, if you
write a subroutine or have a method that performs the quicksort
algorithm, you need to have some method for specifying the
comparison operation. In C, this is usually solved by passing a
pointer to a function that compares 2 values and returns a less
than, equal to, or greater than kind of status. If you had blocks,
you could pass a block of code instead of a pointer to a function.
David Stes wrote a paper in 1998 where he describes Objective C
blocks and talks about the syntax for them. You can read it at
http://users.pandora.be/stes/block98/index.html
Philippe C.D. Robert
very cool, indeed - and what is most interesting to me is the fact that there is some new effort going on to actively maintain the language itself, also from the Apple side! This is great news and very promising after all these years.
-Phil
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep
>
--
Philippe C.D. Robert
Software Engineer
Silicon Graphics, Inc.
Björn Gohla
Hash: SHA1
On Monday 19 November 2001 20:43, Kim Shrier wrote:
> I agree. I would like to see blocks in the GNU Objective C compiler.
what do blocks do, just curious :) .
- --
- --------------------
This is Linux world. On a quiet day, you can hear Windows reboot.
pub 1024D/834F4976 2001-01-07 Björn Gohla (Wissenschaftler, Weltbürger)
<b.g...@gmx.de>
Key fingerprint = 9FF4 FEDA CCDF DA0E 14D5 8129 6C14 3C39 834F 4976
sub 1024g/29571FE2 2001-01-07
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7+YjYbBQ8OYNPSXYRAnjoAKCaLQGGXxQr8VcHnm6ke3swUHv3KACdFnPa
sbA4kJ1PXjYPrQR4mHNvPuM=
=IIXv
-----END PGP SIGNATURE-----
Stefan Urbanek
>
> Ovidiu Predescu wrote:
> > I think
> > David's hate of NS*-ism is irrelevant here, as we are talking about
> > the language and the runtime system.
> >
>
> About a year ago, I was about 50% through adding support for protocols
> to the POC. David Stes raised such an objection to it that I stopped
> work. This is one of the NS*-ism's that David dislikes and it looks
> to me like it would have a direct influence on the language and the
> runtime system.
>
> > There are many neat things in POC that are quite
> > interesting, like blocks for example.
>
> I agree. I would like to see blocks in the GNU Objective C compiler.
>
Me too. And, what also about literal objects like arrays or numbers?
ConstantArray *array = @array(@"Item 1", @"Item 2");
or:
array = @(@"Item 1", @"Item 2");
And numbers:
ConstantNumber *value = @value(1);
or
ConstantNumber *intValue = @1;
ConstantNumber *doubleValue = @1.0;
And even dictionaries:
ConstantDictionary *dict = @{@"Key" = @"Value"};
Some default classes should be used like ConstantArray, ConstantNumber, and it
should be redefined by some gcc option, like now there is
-fconstant-string-class. Then, for example, ConstantNumber can be subclass of
NSValue. Imagine, then you would be able to write:
[dictionary setObject:@12.0 forValue:@"Size"];
Just an idea. I think, it can be userful.
What do you thing about it?
How is it difficult to have something like this?
Stefan
Björn Gohla
Hash: SHA1
On Monday 19 November 2001 21:40, Kim Shrier wrote:
> http://users.pandora.be/stes/block98/index.html
he also mentions class variables, i would like those in gnu objc. what is the
rationale behind not having them so far?
- --
- --------------------
bill says: "this is where you go today!"
pub 1024D/834F4976 2001-01-07 Björn Gohla (Wissenschaftler, Weltbürger)
<b.g...@gmx.de>
Key fingerprint = 9FF4 FEDA CCDF DA0E 14D5 8129 6C14 3C39 834F 4976
sub 1024g/29571FE2 2001-01-07
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7+ZSBbBQ8OYNPSXYRAmWQAJ9BvfbjMKW0NsBqRpCvWZwpWpQKjACglx6x
L348DWyzgbFaXghVLy+Ok8k=
=GlBL
-----END PGP SIGNATURE-----
Ovidiu Predescu
On Mon, 19 Nov 2001 11:55:35 -0800, Ziemowit Laski <zla...@apple.com> wrote:
>
> On Monday, November 19, 2001, at 11:43 , Kim Shrier wrote:
>
> >> There are many neat things in POC that are quite
> >> interesting, like blocks for example.
> >
> > I agree. I would like to see blocks in the GNU Objective C compiler.
>
> Two questions on behalf of the benighted among us (which may include just
> me, but so be it):
> -- What does POC stand for?
POC stands for Portable Object Compiler.
> -- What is this 'blocks' feature in the POC compiler?
This is a feature that comes from Smalltalk, very similar to lambda
functions in Lisp languages. It appeared originally in Stepstone's
compiler/preprocessor and was later implemented by POC.
Here's the POC description of blocks:
http://users.pandora.be/stes/block98/index.html
Here Brad Cox's original description of blocks, called in his paper
"actions":
http://www.virtualschool.edu/cox/CoxTaskMaster.html#Action%20expressions
Regards,
--
Ovidiu Predescu <ovi...@cup.hp.com>
http://orion.rgv.hp.com/ (inside HP's firewall only)
Ovidiu Predescu
> Kim Shrier wrote:
> >
> > Ovidiu Predescu wrote:
> > > I think
> > > David's hate of NS*-ism is irrelevant here, as we are talking about
> > > the language and the runtime system.
> > >
> >
> > About a year ago, I was about 50% through adding support for protocols
> > to the POC. David Stes raised such an objection to it that I stopped
> > work. This is one of the NS*-ism's that David dislikes and it looks
> > to me like it would have a direct influence on the language and the
> > runtime system.
Hm, interesting... I didn't know of that.
> > > There are many neat things in POC that are quite
> > > interesting, like blocks for example.
> >
> > I agree. I would like to see blocks in the GNU Objective C compiler.
> >
>
> Me too. And, what also about literal objects like arrays or numbers?
Yes, this is another thing which comes up quite often in the
improvements list for ObjC.
> ConstantArray *array = @array(@"Item 1", @"Item 2");
> or:
> array = @(@"Item 1", @"Item 2");
>
> And numbers:
> ConstantNumber *value = @value(1);
> or
> ConstantNumber *intValue = @1;
> ConstantNumber *doubleValue = @1.0;
>
> And even dictionaries:
> ConstantDictionary *dict = @{@"Key" = @"Value"};
Since such containers can contain only objects, maybe we can get rid
of intra @ characters, and have only the external @ char? Like this:
array = @("Item 1", "Item 2");
> Some default classes should be used like ConstantArray,
> ConstantNumber, and it should be redefined by some gcc option, like
> now there is -fconstant-string-class. Then, for example,
> ConstantNumber can be subclass of NSValue. Imagine, then you would
> be able to write:
>
> [dictionary setObject:@12.0 forValue:@"Size"];
>
> Just an idea. I think, it can be userful.
>
> What do you thing about it?
>
> How is it difficult to have something like this?
It should not be too difficult to implement it.
Anyways, going back to the list of improvements to the language, we
should probably come up with a list of things that could be added to
the language. Here's a first stab at such a list:
1. Exception handling. I'm thinking specifically of something along
the lines of the Java exception handling, with its very useful
"finally" block. We need to consider how this would fit into the
current OpenStep/Cocoa exception handling, and also how it integrates
with the C++ model. From an implementation point of view, we can
probably reuse the current exception handling infrastructure from C++.
2. Class variables. A "must add" in my opinion, as the current way of
defining them using static variables is far from being acceptable.
3. Blocks, as described by Brad Cox.
4. Syntactic sugars for constant property objects.
Of course, the new features we add to the language should not impact
the existing programs, which should continue to compile and run
correctly.
Any other thoughts on other useful things?
Ziemowit Laski
miss the most is the ability to instantiate ObjC classes or the stack
or in file scope, a la C++. As I understand it, though, this may not
be possible to accomplish since 'alloc...' is not always cleanly
separated from 'init...' in many class implementations. Also, some
clever syntax for initializing such objects would have to be invented.
ObjC++ offers a workaround (of sorts) for this -- one can wrap ObjC
objects in C++ smart pointers.
--Zem
Ovidiu Predescu
> Ovidiu Predescu wrote:
> >
> > On Fri, 16 Nov 2001 16:04:26 +0100, LHel...@kabel.de wrote:
> >
> > > >IMO when we talk about standardizing Objective-C, we talk about the
> > > >runtime system and the language itself. Fortunately the language is
> > > >pretty much similar across compilers, as the most widely used compiler
> > > >is the GNU compiler. It may be a problem with the POC compiler of
> > > >David Stes, we need to talk to him about that.
> > >
> > > David Stes, isn't that the guy that hates any NS*-ism concerning
> > > Objective-C? I remember one thread in comp.lang.objective-c, where David
> > > Stes was ranting about Apple not using Object but NSObject as the root
> > > class of their Objcetive-C implementation.
> >
> > I don't want to defend David Stes here, but as an Objective-C compiler
> > developer I think he ought to represent his ideas in such a
> > discussion. There are many neat things in POC that are quite
> > interesting, like blocks for example. I'm sure some of these ideas
> > would benefit the GNU compiler implementation in the long run. I think
> > David's hate of NS*-ism is irrelevant here, as we are talking about
> > the language and the runtime system.
>
> Some months ago on comp.lang.objective-c I invited him to participate
> in FSF GCC development, independently of Apple's participation, but
> he didn't respond. The invitation is still open, there's nothing to
> keep him from working with the FSF.
Interesting to know...
Anyway, regardless of his willingness to participate, I believe we
should take some of the ideas from the Stepstone language and from POC
and implement them in GCC. There are quite powerful, and we need to
refresh the language a little bit if we want Objective-C to still be
around in the years to come.
Björn Gohla
Hash: SHA1
On Monday 19 November 2001 23:45, Ovidiu Predescu wrote:
>
> 1. Exception handling. I'm thinking specifically of something along
> the lines of the Java exception handling, with its very useful
> "finally" block. We need to consider how this would fit into the
> current OpenStep/Cocoa exception handling, and also how it integrates
> with the C++ model. From an implementation point of view, we can
> probably reuse the current exception handling infrastructure from C++.
>
> 2. Class variables. A "must add" in my opinion, as the current way of
> defining them using static variables is far from being acceptable.
>
> 3. Blocks, as described by Brad Cox.
>
> 4. Syntactic sugars for constant property objects.
>
> Of course, the new features we add to the language should not impact
> the existing programs, which should continue to compile and run
> correctly.
>
> Any other thoughts on other useful things?
5. how about operators?
6. a mechanism to transparently access c types as objects (very handy if you
want to store them in a container)
- --
- --------------------
Something being fool-proof means it takes an engineer to break it.
pub 1024D/834F4976 2001-01-07 Björn Gohla (Wissenschaftler, Weltbürger)
<b.g...@gmx.de>
Key fingerprint = 9FF4 FEDA CCDF DA0E 14D5 8129 6C14 3C39 834F 4976
sub 1024g/29571FE2 2001-01-07
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7+aTubBQ8OYNPSXYRAiHEAKCAiy61sYEi7KAJQepPKzMxFVIR0ACgiu6A
f7yra7RTw6BaGqptsAI+r4s=
=lBtB
-----END PGP SIGNATURE-----
Nicola Pero
> > -- What is this 'blocks' feature in the POC compiler?
> >
>
> subroutine or a method.
With the risk of being flamed, I must say - frankly - that I don't think
it's a good idea to add this to the GNU Objective-C compiler ...
It would make the language more complex, while one of the virtues is its
simplicity.
It would not really add anything you can't do by using C pointers to
functions - or selectors - and similar tools ... even if blocks might be
cooler for smalltalk people, they are one thing more to learn ... one more
tricky syntax to get familiar with ... one more concept ... and their
practical usage is quite limited - if any.
We don't want Objective-C to become crammed with new syntax like C++, so I
vote against it.
I'd vote for implementing real exception handling instead.
David Relson
> > > -- What is this 'blocks' feature in the POC compiler?
> > >
> >
> > A block is a piece of code that can be passed as a parameter in a
> > subroutine or a method.
>
>With the risk of being flamed, I must say - frankly - that I don't think
>it's a good idea to add this to the GNU Objective-C compiler ...
>
>It would make the language more complex, while one of the virtues is its
>simplicity.
>
>It would not really add anything you can't do by using C pointers to
>functions - or selectors - and similar tools ... even if blocks might be
>cooler for smalltalk people, they are one thing more to learn ... one more
>tricky syntax to get familiar with ... one more concept ... and their
>practical usage is quite limited - if any.
I learned Objective-C after 3 years of (nearly) exclusive use of
Smalltalk. I was pleased to get the added speed of C's primitive types
(int, float, etc) and loops, but really missed blocks. A very simple use
of a block is to apply a operation to all elements of a collection (array),
for example:
- (void) arrayDo: (NSArray *) array
{
[ array do: [ :item | item doSomething ]];
}
This example can currently be coded in Objective-C, but isn't nearly as
elegant:
- (void) arrayDo: (NSArray *) array
{
int i;
for (i = 0; i < [ array length ]; i += 1 )
{
NSObject *item = [ array objectAtIndex: i ];
[ item doSomething ];
}
}
Also consider how to process a list, rather than an array. For the block
form, the code would be the same (except the argument would be an NSList
(or some such)). For the for loop variant, it'd be necessary to use an
iterator and code with it.
I would LOVE to see blocks in Objective-C !
>We don't want Objective-C to become crammed with new syntax like C++, so I
>vote against it.
>
>I'd vote for implementing real exception handling instead.
This would also be a valuable addition :-)
David
Erik M. Buck
> Smalltalk. I was pleased to get the added speed of C's primitive types
> (int, float, etc) and loops, but really missed blocks. A very simple use
> of a block is to apply a operation to all elements of a collection
(array),
> for example:
>
> - (void) arrayDo: (NSArray *) array
> {
> [ array do: [ :item | item doSomething ]];
> }
>
> This example can currently be coded in Objective-C, but isn't nearly as
> elegant:
>
> - (void) arrayDo: (NSArray *) array
> {
> int i;
> for (i = 0; i < [ array length ]; i += 1 )
> {
> NSObject *item = [ array objectAtIndex: i ];
> [ item doSomething ];
> }
> }
>
I personally like
[array makeObjectPerformSelector:@selector(doSomething)];
Stephen Peters
> At 12:06 AM 11/19/01, you wrote:
> [...] A very simple use of a block is to apply a operation to all
> elements of a collection (array), for example:
>
> - (void) arrayDo: (NSArray *) array
> {
> [ array do: [ :item | item doSomething ]];
> }
>
> This example can currently be coded in Objective-C, but isn't nearly as
> elegant:
>
> [ standard for loop deleted ]
(Actually, the easy way with the current NSArray would be to do
[ array makeObjectsPerformSelector: @selector(doSomething) ];
)
As long as we're discussing this, I should point out that there is a
way to do this without modifying GNU's current Objective-C syntax,
utilizing some of Marcel Weiher's Higher Order Messaging (HOM)
concepts. With this design, the collection classes implement a -do
method to fetch an iterator, which can then use invocation forwarding
to send the same message to all objects:
- (void) arrayDo: (NSArray *) array
{
[ [ array do ] doSomething ];
}
Some more information from one of Marcel's posts to c.l.objective-.c
is below. If intrigued, you might find it interesting to wander
through Marcel's other posts to that thread, since it mostly ends up
being a comparison of blocks and HOM.
http://groups.google.com/groups?q=g:thl2088540758d&selm=8m5v2e%24l70%241%40news.cs.tu-berlin.de
I understand Marcel has also been shopping the idea around the
Smalltalk forums with some success as well, since the idea has merit
there as well.
--
Stephen L. Peters por...@portnoy.org
PGP fingerprint: A1BF 5A81 03E7 47CE 71E0 3BD4 8DA6 9268 5BB6 4BBE
"Poodle: The other white meat." -- Sherman, Sherman's Lagoon
David Relson
> > I learned Objective-C after 3 years of (nearly) exclusive use of
> > Smalltalk. I was pleased to get the added speed of C's primitive types
> > (int, float, etc) and loops, but really missed blocks. A very simple use
> > of a block is to apply a operation to all elements of a collection
>(array),
> > for example:
> >
> > - (void) arrayDo: (NSArray *) array
> > {
> > [ array do: [ :item | item doSomething ]];
> > }
> >
> > This example can currently be coded in Objective-C, but isn't nearly as
> > elegant:
> >
> > - (void) arrayDo: (NSArray *) array
> > {
> > int i;
> > for (i = 0; i < [ array length ]; i += 1 )
> > {
> > NSObject *item = [ array objectAtIndex: i ];
> > [ item doSomething ];
> > }
> > }
> >
>
>
>[array makeObjectPerformSelector:@selector(doSomething)];
Eric,
Yep. That's another way to skin the same cat. However,
makeObjectPerformSelector: requires defining an additional method. Using
blocks does it inline, which I consider a bit easier. Also, blocks can
have two arguments. For example to sort an array one could use:
array = [ array orderedBy: [ :a :b | [ a lt: b ]]];
Balazs Pataki
>
> ConstantArray *array = @array(@"Item 1", @"Item 2");
> or:
> array = @(@"Item 1", @"Item 2");
>
> And numbers:
> ConstantNumber *value = @value(1);
> or
> ConstantNumber *intValue = @1;
> ConstantNumber *doubleValue = @1.0;
>
> And even dictionaries:
> ConstantDictionary *dict = @{@"Key" = @"Value"};
About 5 years ago, as part of my diploma work, I implemented exactly these
features into NeXT's version of gcc 2.5.8, which came with NEXTSTEP 3.3, using
NSNumbers, NSStrings NSDictionaries as the result of the @"", @() and @{}
operators, ala WebScript. I called it "objectification" (using the @ operator),
and also added operator overloading, for which I know I will get to the C++
hell, but anyway, it was fun. :-) I probably have the sources somewhere and I
can make it available if you like.
---
balazs
Bjoern Giesler
adding my .02 Euro...
Am Dienstag, 20. November 2001 01:33 schrieb Björn Gohla:
> On Monday 19 November 2001 23:45, Ovidiu Predescu wrote:
> > 1. Exception handling.
Seconded. I'd like to see this as well. Personally, though, I'd prefer
something along the lines of Python, which has try...except...finally but
also try...except...else (the else gets executed in case no exception has
occurred).
> > 2. Class variables. A "must add" in my opinion, as the current way of
> > defining them using static variables is far from being acceptable.
Yep.
> > 3. Blocks, as described by Brad Cox.
Yep.
> > 4. Syntactic sugars for constant property objects.
Yep.
> 5. how about operators?
Please, no. IMHO, you don't gain much with this, but it makes debugging a
nightmare. I'm in the process of debugging a program which makes use of
operator overloading in C++. I don't want operators. No. :-/
> 6. a mechanism to transparently access c types as objects (very handy
> if you want to store them in a container)
Hmm. How would this look?
Regards,
--Björn
Helge Hess
> As long as we're discussing this, I should point out that there is a
> way to do this without modifying GNU's current Objective-C syntax,
> utilizing some of Marcel Weiher's Higher Order Messaging (HOM)
> concepts. With this design, the collection classes implement a -do
> method to fetch an iterator, which can then use invocation forwarding
> to send the same message to all objects:
..
Personally I found programming with HOM a bit difficult to understand
and therefore like blocks a bit more (but BTW also think that they only
are really useful if a real garbage collector is available ...)
But anyway: Marcel ported MPWFoundation (that includes, HOM) to
GNUstep/libFoundation - so if anyone is interested, I can probably
upload the GS modified frameworks to gs/contrib or something after
talking to him.
Greetings
Helge
--
SKYRIX Software AG - http://www.skyrix.com
Web Application Technology for Enterprises
Helge Hess
> >I personally like
> >
> >[array makeObjectPerformSelector:@selector(doSomething)];
>
> Eric,
>
> Yep. That's another way to skin the same cat. However,
> makeObjectPerformSelector: requires defining an additional method.
Well, HOM removes that requirement. It's just
[[array do] doSomething];
..
The implementation concept is pretty easy, the object returned by "do"
catches the "doSomething" invocation and executes it on the source
object.
The major problem I have with this approach is, that it requires a
working NSInvocation, which is difficult to have on all platforms ...
> Using
> blocks does it inline, which I consider a bit easier. Also, blocks can
> have two arguments. For example to sort an array one could use:
>
> array = [ array orderedBy: [ :a :b | [ a lt: b ]]];
You can also have as much parameters as you like in HOM.
Helge Hess
> I've been working with ObjC/ObjC++ for almost a year now, and the thing I
> miss the most is the ability to instantiate ObjC classes or the stack
> or in file scope, a la C++. As I understand it, though, this may not
> be possible to accomplish since 'alloc...' is not always cleanly
> separated from 'init...' in many class implementations. Also, some
> clever syntax for initializing such objects would have to be invented.
Well, it's not syntax for it, but in libFoundation you can allocate
objects from the stack using the StackZone:
#include <Foundation/StackZone.h>
{
StackZone *zone;
id stackAllocated;
zone = [[Stack alloc] init];
stackAllocated = [[NSMutableString allocWithZone:zone] init];
}
But IMHO this makes things very complicated to track ... (what happens
if someone outside retain's the string ...)
Stefan Böhringer
[...]
>
> I'd vote for implementing real exception handling instead.
>
What functionality would be added by that?
At what cost?
Best wishes,
Stefan
Bissell, Tim
My list of favoured extensions would be:
* class variable
* sequences - e.g. [textField setBackgroundColor:NSLightGray;
setStringValue:@"foo"];
is equivalent to: [textField setBackgroundColor:NSLightGray];
[textField setStringValue:@"foo"];
With the current idiom being to make methods return void rather than
self, this
construct would not penalise people who write lots of short zero or one
parameter
methods, rather than a few massive, multiparameter methods.
* try/catch/finally exception handling
* Blocks!
regards,
Tim
----------------------------------------------------------------------
If you have received this e-mail in error or wish to read our e-mail
disclaimer statement and monitoring policy, please refer to
http://www.drkw.com/disc/email/ or contact the sender.
----------------------------------------------------------------------
Wim Oudshoorn
what about:
* forward declararion of @protocol's
This will make it easier to map CORBA Idl to ObjectiveC
by just mapping types to @protocol's.
Wim Oudshoorn.
Stephen Brandon
> The major problem I have with this approach is, that it requires a
> working NSInvocation, which is difficult to have on all platforms ...
I'm trying to do some tricky things with delegate message passing between
threads via DO at the moment, and have just discovered the joy of
NSInvocations. What do you mean exactly by saying that it's difficult to have
on all platforms? Is there any platform that it currently does not work on,
that GNUstep does otherwise work on? It's really important for my purposes
that it works on Win32 (MinGW). Can anyone re-assure me in this regard?
Cheers,
Stephen Brandon
> Greetings
> Helge
Dan Pascu
>> array = @(@"Item 1", @"Item 2");
>
>
> NSArray* array=[NSArray arrayWithObjects:@"Item 1",@"Item 2",0];
>
>> or
>> ConstantNumber *intValue = @1;
>> ConstantNumber *doubleValue = @1.0;
>
>
> NSNumber* intValue=[NSNumber numberWithInteger:1];
> NSNumber* doubleValue=[NSNumber numberWithDouble:1.0];
>
>> And even dictionaries:
>> ConstantDictionary *dict = @{@"Key" = @"Value"};
>
>
> NSDictionary* dict=[NSDictionary dictionaryWithObjectsAndKeys:
> @"Key1",@"Value1",
> @"Key2",@"Value2",
> 0];
Less typing maybe? Your examples are twice as long (even longer).
Also more compact syntax? Easier to use too?
> You could even add some macros such as:
>
> #define BD [NSDictionary dictionaryWithObjectsAndKeys:
> #define ED ,0]
>
> to be able to write:
>
> ConstantDictionary* dict = BD @"Key", @"Value" ED;
Eeek. That's UGLY. I wouldn't do that even in plain C.
>> What do you thing about it?
>
> I don't think it's needed.
You can live without indeed, but it would be nice to have.
--
Dan
Björn Gohla
Hash: SHA1
On Tuesday 20 November 2001 09:43, Bjoern Giesler wrote:
> adding my .02 Euro...
btw, is gnustep euro-ready 8-0 ?
> Am Dienstag, 20. November 2001 01:33 schrieb Björn Gohla:
> > 5. how about operators?
>
> Please, no. IMHO, you don't gain much with this, but it makes debugging a
> nightmare. I'm in the process of debugging a program which makes use of
> operator overloading in C++. I don't want operators. No. :-/
i did not write overloding ;) , they could be defined simply as per class
aliases for messages, so you can write
[a + b]
instead of
[a stringByAppendingString: b]
that would make debugging no more difficult than using verbose messages.
to keep their impact limited they could be made uninheritable, so to pass on
an operator you would copy the operator-to-message mapping explicitly, this
would reflect the view that an operator is specific to only one class. doing
it this way could discourage the definition of superfluous and ill-defined
operators.
> > 6. a mechanism to transparently access c types as objects (very handy
> > if you want to store them in a container)
>
> Hmm. How would this look?
as suggested in connection with abbreviated prop lists
int a = 1;
NSMutableArray foo;
<....>
[foo addObject: @a];
[foo addObject: @2];
the same way it is done with string literals there would be classes for c
types, say GSCInt in the example, that would differ from NSValue classes in
that they would only store references. so this does what one expects
int a = 0;
id b;
[@a increment];
b = @a;
printf("%i",a);
printf("%i",[b rawValue]);
prints 1 twice. perhaps provisions in connections with the retain count have
to be made for the case when a goes out of scope while @a is stored in a
global context.
just a thought anyway 8-)
- --
- --------------------
"god not only rolls the dice, he cheats too"
pub 1024D/834F4976 2001-01-07 Björn Gohla (Wissenschaftler, Weltbürger)
<b.g...@gmx.de>
Key fingerprint = 9FF4 FEDA CCDF DA0E 14D5 8129 6C14 3C39 834F 4976
sub 1024g/29571FE2 2001-01-07
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7+nVEbBQ8OYNPSXYRAmOCAKCCPE3zo0eqxBUlaGTzflirO5xaEACeMi8g
Yx+q15qFDnkXCxA2gl/J+QI=
=CMM9
-----END PGP SIGNATURE-----
Björn Gohla
Hash: SHA1
by types you mean corba interfaces? how would that make ir easier :-0 ?
- --
- --------------------
la lojban cu xamgu bangu .i ko viska la'o url. http://www.lojban.org .url
pub 1024D/834F4976 2001-01-07 Björn Gohla (Wissenschaftler, Weltbürger)
<b.g...@gmx.de>
Key fingerprint = 9FF4 FEDA CCDF DA0E 14D5 8129 6C14 3C39 834F 4976
sub 1024g/29571FE2 2001-01-07
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7+nX/bBQ8OYNPSXYRAiyPAKCmBt5h8iEZXe/MJNgTGrqp0JwHtACgl0Vy
lMKcngq9pIpmQJhw3twoBTg=
=kqhv
-----END PGP SIGNATURE-----
Markus Grabert
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 19 November 2001 23:45, Ovidiu Predescu wrote:
> >
> > 1. Exception handling. I'm thinking specifically of something along
> > the lines of the Java exception handling, with its very useful
> > "finally" block. We need to consider how this would fit into the
> > current OpenStep/Cocoa exception handling, and also how it integrates
> > with the C++ model. From an implementation point of view, we can
> > probably reuse the current exception handling infrastructure from C++.
Mhh, what about NSException (NS_DURING, NS_HANDLER and NS_ENDHANDLER) ?
Moreover David Stes explains in http://users.pandora.be/stes/block98.html
how to use blocks for error handling (okay, you have to get used to it).
> > 2. Class variables. A "must add" in my opinion, as the current way of
> > defining them using static variables is far from being acceptable.
definitely.
> > 3. Blocks, as described by Brad Cox.
.. and implemented in POC (http://users.pandora.be/stes/compiler.html).
would a be very nice feature!
> > 4. Syntactic sugars for constant property objects.
> >
> > Of course, the new features we add to the language should not impact
> > the existing programs, which should continue to compile and run
> > correctly.
see below, last question.
> > Any other thoughts on other useful things?
>
> 5. how about operators?
No, operators are the worst thing ever invented!
It makes code more complicated and using operators makes debugging nearly
impossible! KISS. You'd say that it may make your code more readable.
But I'd then say: you're bad coder.
If you REALLY want to use operators, you can use them in ObjC++.
But please odn't introduce this bullshit in plain ObjC!
> 6. a mechanism to transparently access c types as objects (very handy if you
> want to store them in a container)
I'd like to say "another must have"!
Very useful indeed, but it is rather an OpenStep thing than ObjC/ObjC++.
I never understood why there is a @"" operator in ObjC.
If there is a way to introduce a general way of defining constant
objects and converting c types into (untyped id) objects (not NSString,
NSDictionary, NSArray ..., but rather a union struct) - THAT would be
great!
Stan Shebs
>
> With everyone throwing in their favorite extensions,
> what about:
>
> * forward declararion of @protocol's
Zem Laski fixed this bug some months ago, in both Apple's 2.95
compiler and in current (post-3.0) FSF GCC.
Stan
Wim Oudshoorn
> On Tuesday 20 November 2001 12:32, Wim Oudshoorn wrote:
> > With everyone throwing in their favorite extensions,
> > what about:
> >
> > * forward declararion of @protocol's
> >
> > by just mapping types to @protocol's.
>
> by types you mean corba interfaces? how would that make ir easier :-0 ?
Ok, maybe there is another way, but what I want is make CORBA usage
transparent in ObjectiveC. So that for exampe an interface like:
interface XXX
{
YYY giveMyObject (in String name);
};
would work if you implemented your object in Objective C like:
@interface MyImpl: MySuperClass <XXX>
- (id<YYY>) giveMyObject: (NSString*) name;
@end
The CORBA framework could, by using DSI/DII or other lowlevel
orb stuff, process a request on an instance of MyImpl (this is
easy and does not require protocols)
Now the method `giveMyObject' finishes and returns an object, lets say RV.
The CORBA DSI invocation code can now figure out which IDL interface(s)
RV implements by figuring out which protocols it implement.
If DSI knows the return type it can create a corresponding CORBA object
and return this.
DISCLAIMER: I have not thought very hard about it, (and it is
quite some time ago I was contemplating this approach) but it seems
the obvious aproach, maybe make replace <XXX> with <IDL:XXX>
or something similar.
Besides the CORBA stuff.
I sometimes like the added typechecking available with protocols and
not be able to use forward declarations limits its uses and is
just annoying.
But like most requests, it is not essential.
Wim Oudshoorn.
Markus Grabert
> On Tue, 20 Nov 2001, [utf-8] Björn Gohla wrote:
> > > 1. Exception handling. I'm thinking specifically of something along
>
> Mhh, what about NSException (NS_DURING, NS_HANDLER and NS_ENDHANDLER) ?
stupid me! We're talking about ObjC/ObjC++ ...
greetings max
Yann.Le Guen
This is a bit out of topic but...
I'm trying to build up Gstep Base on the latest Cygwin which comes
with gcc 2.95.3-5. Unfortunately it wasn't compiled with ObjC enable
then I'm stopped :-(
On the FAQ of Cygwin I can read the following
"Where is Objective C?
Objective C is not distributed with the Cygwin version of gcc, and there are no plans to do so.
The gcc package maintainer had difficulty building it, and once built there were problems using it.
It appears that there is only minimual support for the Objective C
front-end in the main GCC distribution, anyway."
I didn't notice gcc support for ObjC was "so minimal"...
I would like to know wihch version of our favorite compiler was used
by those of us who have already compiled and install gstep-base. How
did they enable ObjC in it etc...
Later, Yann
Helge Hess
> * forward declararion of @protocol's
>
> This will make it easier to map CORBA Idl to ObjectiveC
> by just mapping types to @protocol's.
I HEAVILY vote for that. I'm missing that a lot.
BTW: AFAIK this is implemented in the Apple gcc !
Stephen Brandon
from core/make/Documentation/MinGW.README. You need to install quite a few
packages in all to make it work, but it can be made to work! The advantage of
using MinGW on top of Cygwin is that you get the nice shells and tools of
Cygwin, whereas the finished compiled binaries do not require the cygwin.dll
to be installed (thus preventing licensing issues).
Actually, it's still quite tricky to get it all working, but definitely
possible (I have done it fairly recently and rely on it).
One of the packages you need to install is libobjc, which gives you the
support that the Cygwin folks left out.
Stephen Brandon
ste...@brandonitconsulting.co.uk
Helge Hess
>
> On Tuesday 20 Nov 2001 8:59 am, Helge wrote:
> I'm trying to do some tricky things with delegate message passing between
> threads via DO at the moment, and have just discovered the joy of
> NSInvocations. What do you mean exactly by saying that it's difficult to have
> on all platforms?
NSInvocation does decode and encode stack/register frames. How stack
frames are laid out is probably one of the most architecture dependend
things in computing ;-)
In other words: NSInvocation basically needs to be rewritten for *any*
platform by a guy who knows core-assember on that platform ;-)
> Is there any platform that it currently does not work on,
> that GNUstep does otherwise work on?
Lots. Anyway, since some months GNUstep supports the use of libffcall as
the NSInvocation backend. libffcall does the NSInvocation stuff for
quite a lot of platforms (search for libffcall on google), so the issue
isn't as huge anymore.
> It's really important for my purposes
> that it works on Win32 (MinGW). Can anyone re-assure me in this regard?
I don't think ix86/Win32 is a problem for libffcall, so this should work
out just fine.
BTW: AFAIK some argument combinations on some platforms can't be decoded
at all !
Doc O'Leary
wrote:
> > > 5. how about operators?
> >
> > Please, no. IMHO, you don't gain much with this, but it makes debugging a
> > nightmare. I'm in the process of debugging a program which makes use of
> > operator overloading in C++. I don't want operators. No. :-/
> i did not write overloding ;) , they could be defined simply as per class
> aliases for messages, so you can write
>
> [a + b]
That *is* overloading. And it sucks.
> to keep their impact limited they could be made uninheritable, so to pass on
> an operator you would copy the operator-to-message mapping explicitly, this
> would reflect the view that an operator is specific to only one class. doing
> it this way could discourage the definition of superfluous and ill-defined
> operators.
You mean ill-defined like using arithmetic operators to do string
manipulation? I've never seen a good argument for this, and yours is
no exception. It *will* make debugging harder, if only because I have
to scan the code and figure out just what + means now based on the
object types and context.
> as suggested in connection with abbreviated prop lists
>
> int a = 1;
> NSMutableArray foo;
> <....>
> [foo addObject: @a];
> [foo addObject: @2];
Uh, and if I wanted to store the character a I would do . . . ?
> int a = 0;
> id b;
> [@a increment];
> b = @a;
> printf("%i",a);
> printf("%i",[b rawValue]);
Your toy example is not compelling. Show me some *real* code that goes
back and forth between C types and objects a lot and odds are it is
just poorly written.
Philippe C.D. Robert
On Tue, 20 Nov 2001 09:43:18 +0100
Bjoern Giesler <gie...@ira.uka.de> wrote:
> adding my .02 Euro...
..adding my .02 Rappen...;-)
> Am Dienstag, 20. November 2001 01:33 schrieb Björn Gohla:
> > On Monday 19 November 2001 23:45, Ovidiu Predescu wrote:
> > > 1. Exception handling.
> Seconded. I'd like to see this as well. Personally, though, I'd prefer
> something along the lines of Python, which has try...except...finally but
> also try...except...else (the else gets executed in case no exception has
> occurred).
> > > 2. Class variables. A "must add" in my opinion, as the current way of
> > > defining them using static variables is far from being acceptable.
> Yep.
> > > 3. Blocks, as described by Brad Cox.
> Yep.
> > > 4. Syntactic sugars for constant property objects.
> Yep.
Uhm ... just one question: why? There are rate situations where such features really are needed. So while I agree that there are (some) situations where such (theoretical/academical) add ons might be 'nice', I much more fear languages which are too complicated, bloated, have too many features etc. ... and I know what I am talking about, I earn my living writing C++ code...;-)
Smart (the car company) once had a brilliant PR strategy saying: Reduce to the max! This is exactly what we need and what makes ObjC such a beautiful language!
> > 5. how about operators?
> Please, no. IMHO, you don't gain much with this, but it makes debugging a
> nightmare. I'm in the process of debugging a program which makes use of
> operator overloading in C++. I don't want operators. No. :-/
Well.... I should actually agree, esp. after my statement above, *but* did you ever do maths in ObjC ... *Very* ugly and *very* annoying (not to speak of string handling in OpenStep/ObjC...).
Anyway, let me throw in another issue. Coming from a parallel world (SGI machines with only 1 CPU are bastards...grin) I'd vote for another feature:
- synchronisable blocks and methods
But then, maybe this would do harm to the simplicity of the language as well...
-Phil
--
Philippe C.D. Robert
Software Engineer
Silicon Graphics, Inc.
Philippe C.D. Robert
just to mention it, I support the idea of having real ObjC exceptions, of course!
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep