Re: Swift generics, circular type declarations, and segfaults, oh my!
Re: Swift generics, circular type declarations, and segfaults, oh my!
- Subject: Re: Swift generics, circular type declarations, and segfaults, oh my!
- From: Charles Srstka <email@hidden>
- Date: Sat, 05 Sep 2015 01:07:44 -0500
> On Sep 4, 2015, at 7:59 PM, Quincey Morris <email@hidden> wrote:
>
> On Sep 4, 2015, at 16:31 , has <email@hidden <mailto:email@hidden>> 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 (email@hidden)
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:
This email sent to email@hidden
| References: | |
| | >Swift generics, circular type declarations, and segfaults, oh my! (From: has <email@hidden>) |
| | >Re: Swift generics, circular type declarations, and segfaults, oh my! (From: Fritz Anderson <email@hidden>) |
| | >Re: Swift generics, circular type declarations, and segfaults, oh my! (From: has <email@hidden>) |
| | >Re: Swift generics, circular type declarations, and segfaults, oh my! (From: Quincey Morris <email@hidden>) |
| | >Re: Swift generics, circular type declarations, and segfaults, oh my! (From: has <email@hidden>) |
| | >Re: Swift generics, circular type declarations, and segfaults, oh my! (From: Quincey Morris <email@hidden>) |