This is the mail archive of the 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++)

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.

ObjC++ offers a workaround (of sorts) for this -- one can wrap ObjC
objects in C++ smart pointers.


On Monday, November 19, 2001, at 02:45 , Ovidiu Predescu wrote:

> On Mon, 19 Nov 2001 22:52:57 +0100, Stefan Urbanek 
> <> 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 <>
> (inside HP's firewall only)
> (my SourceForge page)
> (GNU, Emacs, other 
> stuff)
Ziemowit Laski                   Apple Computer, Inc.                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085

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