Property syntax
Posted: Sat Feb 26, 2011 4:36 pmThese days, all my property declarations tend to follow one of two forms.
1) Combine the "backing" variable declaration into the property declaration, typically for a one-liner like so:
2) Declare the backing variable separately because the property has some logic:
There is an older approach that I no longer use:
...except when maintaining older classes that use this approach.
Because that style has fallen out of use (AFAICT), and in the interest of keeping things succinct and convenient, I suggest that Cobra support:
This is not an original suggestion. It was made earlier by users that were not attached to the original approach like I was, and consequently realized this much sooner than I did.
The "from var" variants would be left in place for legacy reasons. No code breakage. But samples, how-to's and wiki docs would emphasize the newer approach. Here is a more extensive test drive:
...so "from var" disappears and properties can have automatic backing vars regardless of how they are otherwise declared (initial expression (... = SomeValue) vs. type (... as SomeType)).
I think this reads and writes better.
Does anyone foresee any problems this would pose?
Does anyone object?
Do you like or dislike?
1) Combine the "backing" variable declaration into the property declaration, typically for a one-liner like so:
class A
pro foo from var = List<of int>()
2) Declare the backing variable separately because the property has some logic:
class A
var _foo as List<of int>?
pro foo as List<of int>
get
if _foo is nil, _foo = List<of int>()
return _foo
set
_foo = value
There is an older approach that I no longer use:
class A
var _foo as List<of int>
# ...
pro foo from var
...except when maintaining older classes that use this approach.
Because that style has fallen out of use (AFAICT), and in the interest of keeping things succinct and convenient, I suggest that Cobra support:
class A
pro foo = List<of int>()
# and when you don't have an initial value:
pro bar as IDictionary<of String, int>?
# where the absence of the implementation of 'get' and 'set'
# implies storage by a backing variable
This is not an original suggestion. It was made earlier by users that were not attached to the original approach like I was, and consequently realized this much sooner than I did.
The "from var" variants would be left in place for legacy reasons. No code breakage. But samples, how-to's and wiki docs would emphasize the newer approach. Here is a more extensive test drive:
class Customer
pro name = '(noname)'
pro address as Address?
get orders = List<of Order>()
# or if you want the property type to be more general:
get orders as IList<of Order> = List<of Order>()
get balance as number
bal = 0.0
for order in orders, bal += order.bal
return bal
...so "from var" disappears and properties can have automatic backing vars regardless of how they are otherwise declared (initial expression (... = SomeValue) vs. type (... as SomeType)).
I think this reads and writes better.
Does anyone foresee any problems this would pose?
Does anyone object?
Do you like or dislike?