This line of thought suggests that allowing stored properties for same-module
extensions is not only much more feasible to implement, but also makes more
sense at the user level.
> On Nov 10, 2016, at 4:36 AM, Jay Abbott wrote:
>
> Perhaps some types don’t lend themselves to being extended?
>
Perhaps some types don’t lend themselves to being extended?
Intuitively I would think any extensions should not affect the core
behaviour at all. So if I extended a type by adding a property x, two
instances with everything else the same and different values of x should
still be considered equal b
Has anybody thought about the semantic issues of out-of-module extensions with
stored properties apart from the implementation issues?
Such properties could potentially wreak havoc with the semantics of the type
being extended. How would these properties play nice with an existing
definition of
> On Oct 16, 2016, at 6:56 PM, Benjamin Spratling via swift-evolution
> wrote:
>
>> Benjamin:
>>
>> Implementation wise, weak does *not* currently have the effect of storing
>> associated values. It does however mean that any object with weak references
>> stays allocated after being deinited
>> Benjamin:
>>
>> Implementation wise, weak does *not* currently have the effect of storing
>> associated values. It does however mean that any object with weak references
>> stays allocated after being deinited, until all the weak references are
>> evaluated and zeroed (they are not zeroed
T.J.: This would not replace the need for stored properties in extensions.
For example: Imagine adding a property to UIView in an extension, then
recursively traversing a view hierarchy and accessing the property. This
thought experiment should quickly show you why wrapping and adding
properties (o
How much would convenient method forwarding when wrapping change how
desirable this feature is? I am hesitant to add storage to already
allocated instances if we can avoid it.
On Sun, Oct 16, 2016 at 5:02 PM, Jay Abbott via swift-evolution <
swift-evolution@swift.org> wrote:
> Greg:
>
> I've CCed
Greg:
I've CCed you in case you want to respond to my comments below about
potentially optimising "extensionIvar" access without using a dictionary.
See my response to Haravikk below.
Benjamin:
Implementation wise, weak does *not* currently have the effect of storing
associated values. It does h
Currently, we can expect that fields of a type are all collected in the
same place. This expectation applies more for "static" and less for
"dynamic" types.
So I agree with the idea for @objc classes, strongly disagree for structs,
and disagree for regular classes.
_
I’m haven’t read the implementation, but as I see it, “weak” has the effect of
storing associated values. Can that mechanism be made generic?
> +1 from me too for internal extensions; I think this is the logical place to
> start for now so we can see how many use cases this actually covers.
>
> On 15 Oct 2016, at 02:01, Paul Cantrell via swift-evolution
> wrote:
>
>
>> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution
>> wrote:
>>
>> Let extensions introduce stored properties, but only in the same module as
>> the type’s definition. Then, the compiler can just take
+1 for me for "in-module" as a stop-gap, since I imagine it would be the
quickest, and least disruptive, way to make this happen.
I would add the caveat that if we do so, I really hope we commit to making
stored properties available *everywhere* later.
Even though it's more often than not "in-mod
> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution
> wrote:
>
> Let extensions introduce stored properties, but only in the same module as
> the type’s definition. Then, the compiler can just take any extensions into
> consideration when it’s determining the size of the type, ju
I was thinking for reference types we would probably want to use the extra
space in the refcount field (as discussed earlier in the thread). For value
types, we might want to have a single data structure (probably COW) holding all
associated values for the value types on the stack frame. That
Karl, interesting point... perhaps a similar scheme could work for value
types (using the COW refcount)?
On Thu, 13 Oct 2016 at 16:02 Karl Wagner wrote:
> That's great! I suppose the idea of allocating a bit of extra storage for
> similar data in value types is some sort of heresy?
>
> Would the
That's great! I suppose the idea of allocating a bit of extra storage for
similar data in value types is some sort of heresy?
Would there be a conceptual reason for that; which explains why it's okay for
reference-types but not for values? Personally I feel like it's a kind of C
legacy, due to
> On Oct 11, 2016, at 3:02 PM, Jay Abbott via swift-evolution
> wrote:
>
> Implementation idea No. 4:
>
> The basic concept is that the dynamic linker would fixup the offsets as well
> as relocating the addersses, allowing the size of objects (and maybe
> structs?) to change at link-time. Th
Interestingly, if all the stored properties defined in extensions could be
determined at link-time, the size/layout of the side-table could include
them directly, removing the need for further indirection. The offsets would
still need to be fixed up, which would add some complexity to the
implement
Wow, that's a very interesting post. Sounds a lot simpler to implement than
my idea about fixing up offsets in the linker and preserves binary
compatability just the same.
I got some complaints when I first started talking about this that the
runtime would have to track extra pointers and performa
> I think the language devs must have some idea how this will work, but
> don't seem to want to share/discuss it at the moment. I was hoping for
> some feedback about my implementation ideas - whether they are along the
> right lines, or way off, or not necessary (because the implementation
> stra
I agree Karl, especially the bit about the difficulty of implementation
being the limiting thing here.
I think the language devs must have some idea how this will work, but don't
seem to want to share/discuss it at the moment. I was hoping for some
feedback about my implementation ideas - whether
> On 10 Oct 2016, at 21:15, Charles Srstka via swift-evolution
> wrote:
>
> Right. The question is whether we *need* to add stored properties
> out-of-module, and what the use case for that is. To me it seems that adding
> them in-module is by far the more common use case, for the purposes of
Yes, there are valid use cases.
For example, in case of many UI elements, you do not have control over their
instantiation and need to associate a "help description" with them as an
example. Which can be done by an additional property helpDescription added to
NSView/UIView.
Another example th
Right. The question is whether we *need* to add stored properties
out-of-module, and what the use case for that is. To me it seems that adding
them in-module is by far the more common use case, for the purposes of
implementing protocols.
At any rate, the rewrite option would be a great addition
> On Oct 10, 2016, at 1:13 PM, Jay Abbott wrote:
>
> I understand Charlie. A few points though:
> a) I'm talking about pure Swift, this is absolutely nothing to do with
> Objective-C;
Sure, but in either case you will need to somehow solve locking of the
structure holding the additional value
I understand Charlie. A few points though:
a) I'm talking about pure Swift, this is absolutely nothing to do with
Objective-C;
b) If you read back on the AO thread you'll see that initially I was
thinking "I want AO because it will give me stored properties in
extensions" when really I should have
No, I've also suggested how it would be implemented. It would, as I've
described, require support from the compiler and runtime - the protocol
conformance would tell the compiler to include an extra space in the instance
layout for [AnyHashable : Any], which would get to be used by the runtime t
Charles,
That would be good. It is a nicer way to write what is already possible to
achieve, but it's not a way to 'implement' stored properties in extensions.
On Sun, 9 Oct 2016 at 21:45 Charles Srstka wrote:
> *Replace both instances of “class C: P” with just “class C” since the
> conformance
*Replace both instances of “class C: P” with just “class C” since the
conformance comes in the extension. That’s what I get for writing this quickly.
Charles
> On Oct 9, 2016, at 3:43 PM, Charles Srstka wrote:
>
> protocol P {
> var foo: String { get }
> func bar()
> }
>
> protoco
How about a 5th way?
5. Let extensions introduce stored properties, but only in the same module as
the type’s definition. Then, the compiler can just take any extensions into
consideration when it’s determining the size of the type, just as if the
properties had been declared in the type. Decla
Charlie,
What you suggest defines how you would use it from your code, not how it
would be implemented in the language. If you look at my AO implementation
it does what you say:
https://github.com/j-h-a/AssociatedObjects/blob/develop/AssociatedObjects/AssociatedObjects.swift
i.e. has a protocol ca
There is a 4th way.
Introduce an internal protocol Associatable, which would tell the compiler to
add an additional (hidden) field to the object which would include the
"dictionary" of key -> value associated values. (It would be off-limits to
extensions, of course).
This way:
- it won't be a
I have been thinking further on this and in addition to my previous two
thoughts about implementation, I have had another idea...
3. If there is a bit spare in the object header somewhere (that is
currently always zero), this could be used to signify the presence of an
additional struct that immed
Are stored properties in extensions already being discussed elsewhere? Is
this one of those deferred-but-not-indexed-anywhere subjects?
I wonder how stored properties could potentially be implemented, I can only
think of two ways:
1. An extra pointer per instance (with resulting ABI compatability
34 matches
Mail list logo
