This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ObjC additions (Was: Re: PROPOSAL: Objective-C++)


On Mon, 19 Nov 2001 22:52:57 +0100, Stefan Urbanek <stefanurbanek@yahoo.fr> wrote:

> 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?

Regards,
-- 
Ovidiu Predescu <ovidiu@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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]