On Sep 4, 2015, at 16:31 , has <[email protected]> wrote:
>
> At risk of derail...
Do you mean “derail” or “detail”? I feel like I’m drowning in details.
My (first) “huh?” was to ask why you would prefer SomeClass
().makeASomeClassInstance () to SomeClass.makeASomeClassInstance (). I’m not
sure, but I think your answer is that *either* (a) you already have a SomeClass
instance, so who cares, *or* you don’t, but who cares? That is, your API is
deliberately (and presumably beneficially) conflating objects as specifiers (of
what data to retrieve) or retrievers (of the data itself).
What I mean is, in:
TextEdit().documents[1].text.words.get()
the instances represented by ‘TextEdit()’, 'TextEdit().documents[1]’,
'TextEdit().documents[1].text’ are just setting the context for what the
instance represented by 'TextEdit().documents[1].text.words’ is being asked to
retrieve.
If that’s what it is, then OK. (Even if it’s not that, it’s not up to me to try
to derail you, apart from throwing in that ‘huh?’.) So that’s that, I’ll stay
out of it. :)
Regarding the rest of what you’re trying to do, the answer is no, you cannot do
it, isn’t it? You cannot have a method that returns objects of any of several
types *known at compile time*. The compiler simply won’t know which behaviors a
(potential) returned object would have, so it can’t compile code that uses such
references**. This is true of both Swift and Obj-C. Isn’t it?
** Without leaving validation to run-time, which you said you don’t want to do.
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
