> On Sep 4, 2015, at 7:59 PM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Sep 4, 2015, at 16:31 , has <hengist.p...@virgin.net > <mailto:hengist.p...@virgin.net>> 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. :)
The way I’m reading it, he or she is wrapping an application’s scripting dictionary, creating a Swift object to wrap each construct that would represent a noun, so to speak, in AppleScript. However, these entities are expensive to obtain, involving IPC, so s/he’s loading them lazily. What this means is that the objects are all going to have some number of properties that, when the user accesses them, will necessitate creating a new wrapper object. > 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. I’m not the most knowledgeable about AppleScript, but what it sounds like from s/he’s saying is that the relationships between the AppleScript objects fall into three main categories, and for each type of object, there will be only one specific class to which each of the three relationships can point, so the object should be representable by a Swift generic with three parameterized types. However, if an object points to more of the same type of object, this results in something like Foo<Foo>, and this causes either the compiler or the runtime to crash since it’s apparently not built to handle a generic being passed an object of its own type (honestly, this sounds like something warranting a Radar). S/he is asking if anyone knows of any way around this. Charles _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
