I'm usually a fan of dependency injection over central configuration, though I understand that central configuration is usually less effort. It occurred to me that if we allow direct access to the pod-level configuration, that someone could change to dependency injection without rewriting most of their code. For example (in some method somewhere):
// I don't syntactically know in this method
// whether I'm using a slot or a pod-level value.
service := SomeService(serviceUri)
If you wanted to know, you'd have to look in this type or a super type or understand from docs, tutorials, or your IDE. (The IDE would make it especially easy.) This ambiguity is somewhat awkward without an IDE but not killer. However, this same ambiguity would allow you to turn a pod-level config into a slot (and use injection) without changing your code that uses it, at least in many cases. I think that's a plus.
Further, I think that saying configSymbol by itself should give you the configured value, whether that's the original value or an overridden or localized value. The most specific is the one you'll want almost 99% of the time, I bet. I think only very occasionally you'd want to see the original value (or perhaps other locales or whatnot). Therefore, if all we usually need is the value, there's less need to say things like @config.val or config#.val or whatnot.
Note that there's some relation here to Stephen's recommendation of allowing configuration of static fields in classes. I'm not giving a full opinion on that, but explicit static field reference (or even qualified pod::config) is obviously less syntactically ambiguous, thereby avoiding my discussed pros and cons.
brianWed 29 Jul 2009
are you proposing that symbols are accessed just like fields with no extra syntax?
that would requiring pulling a ton of identifiers into the namespace on every using import
tompalmerWed 29 Jul 2009
are you proposing that symbols are accessed just like fields with no extra syntax?
That's my proposal. I'm not claiming it's ideal. I think it has pros (including simplicity and the DI-friendly nature I discussed) and cons (harder to track things mentally as well as the namespace polution you mention). I think locals could safely automatically overrule such using imports in the namespace concern. Not sure about slots and inherited slots (and it-block names) since they could all lead to programmer confusion.
Hrmm. Maybe you are right that it would cause too much trouble.
tompalmer Wed 29 Jul 2009
I'm usually a fan of dependency injection over central configuration, though I understand that central configuration is usually less effort. It occurred to me that if we allow direct access to the pod-level configuration, that someone could change to dependency injection without rewriting most of their code. For example (in some method somewhere):
If you wanted to know, you'd have to look in this type or a super type or understand from docs, tutorials, or your IDE. (The IDE would make it especially easy.) This ambiguity is somewhat awkward without an IDE but not killer. However, this same ambiguity would allow you to turn a pod-level config into a slot (and use injection) without changing your code that uses it, at least in many cases. I think that's a plus.
Further, I think that saying
configSymbolby itself should give you the configured value, whether that's the original value or an overridden or localized value. The most specific is the one you'll want almost 99% of the time, I bet. I think only very occasionally you'd want to see the original value (or perhaps other locales or whatnot). Therefore, if all we usually need is the value, there's less need to say things like@config.valorconfig#.valor whatnot.Note that there's some relation here to Stephen's recommendation of allowing configuration of static fields in classes. I'm not giving a full opinion on that, but explicit static field reference (or even qualified
pod::config) is obviously less syntactically ambiguous, thereby avoiding my discussed pros and cons.brian Wed 29 Jul 2009
are you proposing that symbols are accessed just like fields with no extra syntax?
that would requiring pulling a ton of identifiers into the namespace on every
usingimporttompalmer Wed 29 Jul 2009
That's my proposal. I'm not claiming it's ideal. I think it has pros (including simplicity and the DI-friendly nature I discussed) and cons (harder to track things mentally as well as the namespace polution you mention). I think locals could safely automatically overrule such
usingimports in the namespace concern. Not sure about slots and inherited slots (and it-block names) since they could all lead to programmer confusion.Hrmm. Maybe you are right that it would cause too much trouble.