On Dec 4, 2007 8:41 AM, Jonathan deWerd <email@hidden> wrote:
> This would be a nice feature, but apple probably had little use for
> it, since their collection classes only contain ObjC objects. Plus it
> would require a little more compiler and language magic (the actual
> return type of foo's implementation of countByEnumerating...: would
> have to be known before generating foreach code, and the code would
> have to be tailored to fit each object, which is ugly and has a slew
> of downsides).
No, it wouldn't. If you look at the code in GCC, you'll see that the
for...in language feature is really nothing more than a fancy macro.
It would be a simple matter to turn the code that the compiler
transforms the for...in statement in to (posted previously) in to a C
preprocessor macro, something along the lines of forin(type, var,
collection). Because the feature is embedded in the compiler, it can
be slightly fancier with for(TYPE VAR in COLLECTION), but
pragmatically there is no difference between the hypothetical forin()
macro and for...in syntax.
> This doesn't really answer your question about having
> pointers to other types, but it is likely there are garbage collection
> and other memory management concerns that force them to use ids.
>From looking at the GCC code, I don't think this is the case. It is
literally implemented as a fancy macro, so it's fair to say that a
preprocessor macro in the form of forin(var, collection) that expands
to the code posted previously, and the code generated by the compiler
transformation are very likely identical. Provided that's true (and I
believe it is), one can reason about such issues and I don't see how
GC or other memory management issues enter in to it. Any strong or
weak type qualifiers would get dragged along with the variable type,
for example.
> Apple probably thought you could make your own foreach macro +
> protocol if you had a truly compelling reason to do so.
While this is certainly true, I would have to say that this is a poor
choice and serves to highlight that the for...in, as implemented, is
fundamentally flawed.
Hypothetically, if you're designing a class or framework that requires
you to hack in your own foreach() preprocessor macro.... it only takes
a few seconds of consideration to see just how far that scales, with
the result being a proliferation of prefixed, one-off XYforeach()
macros that are virtually identical, all of which are required only to
work around an artificial limitation in how the current for...in is
implemented.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
