November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | On 2012-11-21 19:11, Namespace wrote: > Nothing, if enough people say that they need him I will implement them > again. > But maybe better. :) Cool :) > const in D1 isn't the const as in D2 and enforce only that the object > cannot be assigned again? Strange. O.o Yes, it worked a bit more like "const" in C than in C++. I just came to think of this since you mentioned "lazy const". > But then I will think about it. Schould not be much work. Thanks. -- /Jacob Carlborg |
November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | On 2012-11-21 10:37, Namespace wrote: > After some consideration, I now have the following things, which I wish > that D would have them built-in: > - scope arrays: like static arrays, but you can init them at runtime > with constant and non-constant expressions and they are resizeable if > you have to. They will (so far) allocated on the heap and will released > at the end of the lifetime of the scope. Furthermore you _can_ reserve > memory, but by default the length and the capacity of the array are > equal. Means: you don't pay (by default) for memory which you don't > need. Syntax idea: 'scope int[5] arr;' and 'scope int[some_runtime_int] > arr;' > - lazy const: Just a spontaneous idea: I have often variables, which > aren't initialize in the CTor, but they are initialized only once, and > then they should be constant. That isn't possible yet. Therefore I whish > something like: lazy const var; > - And of course: not-null references. There is not much to say. > Current syntax idea comes from C++: Foo& f = other_f; > > So what do you mean about these ideas? And if you like one, what do you > mean about the syntax? A property shortcut syntax would be cool to have. class Foo { @property int bar; } Lowered to: class { private int bar_; @property int bar () { return bar_; } @property int bar (int value) { return bar_ = value; } } It would also be nice if you could manually implement any of the getter or setter and none would be generated in that case. -- /Jacob Carlborg |
November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | > A property shortcut syntax would be cool to have.
>
> class Foo
> {
> @property int bar;
> }
>
> Lowered to:
>
> class
> {
> private int bar_;
>
> @property int bar () { return bar_; }
> @property int bar (int value) { return bar_ = value; }
> }
>
> It would also be nice if you could manually implement any of the getter or setter and none would be generated in that case.
Hm, I like the Idea.
But I would prefer:
private:
int _bar in(int val) {
_bar = val;
} out {
return _bar;
}
which results in:
private:
int _bar;
@property int bar() { return _bar_; }
@property void bar(int val) { _bar = val; }
|
November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | > It means to try to use your feature(s) to rewrite/modify several of those little programs, and then take at how much frequently you use those new features, what advantages they give you, and so on. An usability experiment.
>
> Bye,
> bearophile
A short question: what ist your imagination of a perfect not-null references? What should they can do, how they should assigned? Only with (valid) lvalues, or even with rvalues? Tell me a bit of your thoughts.
|
November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | Namespace: > A short question: what ist your imagination of a perfect not-null references? What should they can do, how they should assigned? Only with (valid) lvalues, or even with rvalues? Tell me a bit of your thoughts. I put some partial notes here: http://d.puremagic.com/issues/show_bug.cgi?id=4571 See in particular: http://research.microsoft.com/pubs/67461/non-null.pdf Bye, bearophile |
November 22, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Wednesday, 21 November 2012 at 23:47:55 UTC, bearophile wrote:
> Namespace:
>
>> A short question: what ist your imagination of a perfect not-null references? What should they can do, how they should assigned? Only with (valid) lvalues, or even with rvalues? Tell me a bit of your thoughts.
>
> I put some partial notes here:
> http://d.puremagic.com/issues/show_bug.cgi?id=4571
>
> See in particular:
> http://research.microsoft.com/pubs/67461/non-null.pdf
>
> Bye,
> bearophile
Thank you. So you would prefer it if they accept ravlues _and_ lvalues. Ok.
|
November 22, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | On 2012-11-21 21:48, Namespace wrote: > Hm, I like the Idea. > But I would prefer: > private: > int _bar in(int val) { > _bar = val; > } out { > return _bar; > } The point was to make the syntax short. I wouldn't consider this much of an improvement. -- /Jacob Carlborg |
November 22, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Thursday, 22 November 2012 at 07:14:38 UTC, Jacob Carlborg wrote:
> On 2012-11-21 21:48, Namespace wrote:
>
>> Hm, I like the Idea.
>> But I would prefer:
>> private:
>> int _bar in(int val) {
>> _bar = val;
>> } out {
>> return _bar;
>> }
>
> The point was to make the syntax short. I wouldn't consider this much of an improvement.
IMO is too short not always the best. Therefore I like the C# syntax with set and get. The aquivalent of this in D is IMO 'in' and 'out'.
|
November 22, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | On Thursday, 22 November 2012 at 11:55:08 UTC, Namespace wrote: > On Thursday, 22 November 2012 at 07:14:38 UTC, Jacob Carlborg wrote: >> On 2012-11-21 21:48, Namespace wrote: >> >>> Hm, I like the Idea. >>> But I would prefer: >>> private: >>> int _bar in(int val) { >>> _bar = val; >>> } out { >>> return _bar; >>> } >> >> The point was to make the syntax short. I wouldn't consider this much of an improvement. > > IMO is too short not always the best. Therefore I like the C# syntax with set and get. The aquivalent of this in D is IMO 'in' and 'out'. I believe Jacob is referring to C#'s auto-implemented properties: http://msdn.microsoft.com/en-us/library/bb384054.aspx The compiler generates the get/set pair and backing store from the user's single-line declaration. So, @property int bar(); would expand to: private int bar_; @property void bar(int value) { bar_ = value; } @property int bar() { return bar_; } |
November 22, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Chapman | Oh, I didn't know that, thanks. |
Copyright © 1999-2021 by the D Language Foundation