on Tue Aug 02 2016, Rick Mann wrote:
>> On Aug 2, 2016, at 13:07 , Dave Abrahams via swift-users
>> wrote:
>>
>>
>> on Mon Aug 01 2016, Rick Mann wrote:
>>
>
On Aug 1, 2016, at 19:18 , Jack Lawrence wrote:
Jens: Why? There are
> On Aug 2, 2016, at 13:07 , Dave Abrahams via swift-users
> wrote:
>
>
> on Mon Aug 01 2016, Rick Mann wrote:
>
>>> On Aug 1, 2016, at 19:18 , Jack Lawrence wrote:
>>>
>>> Jens: Why? There are significant benefits to value semantics for
>>> this
on Mon Aug 01 2016, Rick Mann wrote:
>> On Aug 1, 2016, at 19:18 , Jack Lawrence wrote:
>>
>> Jens: Why? There are significant benefits to value semantics for
>> this type of problem, for the reasons laid out in the WWDC
>> videos. It would be helpful to know why you disagree
I happen to agree with Jens, though Dave Abrahams (and Crusty) might disagree
with me. The number one consideration for choosing between a value type and a
reference type is “do I want value semantics or reference semantics?” If I want
to talk about a particular shape, talk about “that one”, I
> On Aug 1, 2016, at 7:24 PM, Rick Mann wrote:
>
> But my model has implicit reference semantics: multiple instances of a part
> can share a PartDefinition; it is intended that if the PartDefinition
> changes, all the referencing instances get the change.
Bingo. That’s
> On Aug 1, 2016, at 19:18 , Jack Lawrence wrote:
>
> Jens: Why? There are significant benefits to value semantics for this type of
> problem, for the reasons laid out in the WWDC videos. It would be helpful to
> know why you disagree in this case—maybe there are solutions to
Jens: Why? There are significant benefits to value semantics for this type of
problem, for the reasons laid out in the WWDC videos. It would be helpful to
know why you disagree in this case—maybe there are solutions to the issues
you’re thinking of.
Rick: I’d think that value semantics would
> On Aug 1, 2016, at 16:32 , Jens Alfke wrote:
>
>
>> On Aug 1, 2016, at 1:19 AM, Rick Mann via swift-users
>> wrote:
>>
>> It seems like reference semantics are more appropriate here.
>
> Yes, they are. (Just because structs exist doesn’t mean
> On Aug 1, 2016, at 02:25 , Rimantas Liubertas wrote:
>
>
> I did. That's one of the two talks I mentioned.
>
> Well, so they did cover this, didn't they? You move item, you get the new
> struct with the new position. And if you save the old one, you have a cheap
> way
> On Aug 1, 2016, at 02:14 , Rimantas Liubertas wrote:
>
>
> Similarly, in the diagramming example from the WWDC videos, how would that
> app handle the user editing existing Drawables in the Diagram? Let's say you
> allow the user to click on a Drawable and drag it to
> Similarly, in the diagramming example from the WWDC videos, how would that
> app handle the user editing existing Drawables in the Diagram? Let's say
> you allow the user to click on a Drawable and drag it to another location
> in the canvas. Is this reasonable:
>
See this talk too:
I watched the WWDC 2015 video about protocol-oriented programming and value
semantics. Both of them use the example of a diagramming app, where the user
can make a diagram of circles and polygons. They make a protocol for Drawable
(makes sense), and then make Circle and Polygon structs.
I'm
12 matches
Mail list logo