Buzz H. wrote:
[…]
The syntax of a.PAYMENT_TYPES won’t work. I am not sure if you meant it
to work or you were just using it for the sake of explanation.
I meant “assuming proper definition such that it would work, how would
you want it to behave?”. It’s possible to get it to work, just
unnecessary.
[…]
Without trying to be arguementative, Ruby won’t allow this.
class PaymentType
def payment_types
This syntax defines an instance method.
["Check", "Credit Card", "Purchase Order"]
end
PAYMENT_TYPES = payment_types
This syntax calls a class method, since we’re outside of any method
definition here.
end
This will error: NoMethodError
Right. You’re defining an instance method, then trying to call a class
method that you haven’t defined. For this to work, you’d need to do
PAYMENT_TYPES = @some_instance.payment_types.
But I get your point, which has enhanced my understanding. Things that
relate to the class in general, things that shouldn’t be redefined, like
Math:PI are controlled only by class methods.
Sort of. I was more trying to say that while you could set up instance
constants, there is no point.
So, in the above example,
if the payment_types were to change dynamically as the program executed,
I would not use a constant, I would setup getter and setter methods.
It’s not so much about changing dynamically as it is about whether the
property conceptually belongs to the class or the instance.
Do you understand the difference between class and instance attributes?
It sounds like you don’t, or else this would all be clear to you.
[…]
Sure there is: self.class::CONSTANT.
Again, this syntax won’t work, if using self.payment_types
pt = PaymentType.new
pt.PaymentType::PAYMENT_TYPES
Error: NoMethodError: undefined method ‘PaymentType’
Yes. That’s not what I said. I said pt.class::PAYMENT_TYPES, which will
absolutely work.
pt.PaymentType will look for an instance method called PaymentType,
which you haven’t defined.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]