Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: FSOCLF (Frequently-Suggested Objective-C Language Features)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FSOCLF (Frequently-Suggested Objective-C Language Features)

On 29 Dec 2003, at 21:03, Greg Parker wrote:

Some common requests for new features:

Hmm...none of these requests seem they're solving burning issues to me. Are these actually common requests from experienced Objective-C coders or "checklist items"? I think it would be important to take a step back and check what the underlying problem is, how relevant it is and if the proposed solution is the best one.

1. Namespaces for classes, as seen in C++ and Java
* What would `objc_getClass("fully.qualified.classname")` do? What would `objc_getClass("unqualifiedclassname")` do?
* How would these namespaces interact with C++ namespaces in Objective-C++ code?

Although this sounds like a good thing in theory (and it probably isn't a "bad" thing per se), I don't find identifier clashes to be an issue, although the proliferation of named constants has increased that risk. Is this such a pressing problem, in practice (!), for anyone that it needs solving in ways beyond what we have now?

I am guessing that even for those of us that do experience non-resolvable identifier clashes, such occurrences are pretty rare (you need a project that imports two non-source frameworks that don't adhere to naming conventions...). So maybe we should look at a way of resolving identifier clashes when they do occur.

Of course, one good way of avoiding identifier clashes is to actually *use* the name-spaces that classes provide and export fewer global constants and enums and stuff...

2. Class variables, as seen in C++ and Java static member variables
* What would the syntax for these be?

This sounds like a "nice to have" to me, although I've only had this requirement very infrequently.

3. More-formalized "informal protocols". Informal protocols currently exist only in the documentation.
* What would the syntax look like?
* How would `-conformsToInformalProtocol:` behave in the face of "optional" methods? Would the protocol have a "protocol version number" of some sort?

Huh? Can you explain what this is supposed to be? I am not at all sure what you are trying to achieve here.

However, I have noticed that, in practice, "formal" protocols have been far less useful than I expected when they were introduced. I have also noticed that Apple hasn't been using them much at all, instead relying on informal protocols, so maybe my experience isn't unique. Maybe we should look at our current protocols and see why they aren't as useful as they could be?

Just a couple of things off the top of my head:

- default "implementation"

This could be used instead of informal protocols in situations where you want to declare/define the messages that may be there but don't want to force adopters to actually have to implement all the methods. Instead protocols can be provided with a "do-nothing" implementation by default, so the sender of the protocol can simply send its message and not worry about checking.

- sub-protocols

Allows you to declare a protocol as a sub-protocol of an existing protocol, which is useful when you actually want to do protocol-based type-checking in situations where the "full" protocol already exists.

- protocol-forwarding / handling

More in the "far away" region, but something that I've had a need for on quite a number of occasions: allow a protocol to be forwarded to some other object wholesale, without going through forwardInvocation:

- more runtime support

Creating and adopting protocols would be top of the list.


4. Non-fragile instance variables, as seen in Java but not in C++.
* How could this be done while retaining backwards compatibility? How would this interact with existing classes? Would it be possible to add non-fragile ivars to a class with existing fragile ivars and existing fragile subclasses?
* How robust should non-fragile ivars be? Making them more robust also makes access slower. For example, making access to public ivars robust even if the ivars are re-ordered in the class definition is more expensive than making subclassing robust but leaving public ivar access fragile.

Again, actual breakage due to a superclass needing additional instance variables seems like a rare occurrence to me, and again, I think it may be better to deal with that particular issue when it does occur rather than make wholesale changes.

A while back, I though about ways of adding instance variables to a superclass without breaking subclasses, and came up with a "hack" based on indexed instance variables. The rough outline is as as follows: a class would simply define how much extra space it needs for these "extra" instance variables (they could be the "non-fragile" ones referred to above) and access would be via the IV() macro ( base + class->instance_size + variable-offset ), as long as that macro is changed back to not calling an external function.

It is even possible to have subclasses add more of these extra variables: you just add up the extra-sizes requested by the classes and set up a base-offset for the extra-variables of each class. With compiler support most of that could actually be fairly transparent, and it even seems possible to add extra variables at runtime.

It does require the +alloc... methods playing along nicely.

Marcel

--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
1d480c25f397c4786386135f8e8938e4
_______________________________________________
objc-language mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/objc-language
Do not post admin requests to the list. They will be ignored.
References: 
 >FSOCLF (Frequently-Suggested Objective-C Language Features) (From: Greg Parker <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.