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
Without trying to be arguementative, Ruby won’t allow this.
This syntax defines an instance method.
["Check", "Credit Card", "Purchase Order"]
PAYMENT_TYPES = payment_types
This syntax calls a class method, since we’re outside of any method
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
Error: NoMethodError: undefined method â€˜PaymentTypeâ€™
Yes. That’s not what I said. I said pt.class::PAYMENT_TYPES, which will
pt.PaymentType will look for an instance method called PaymentType,
which you haven’t defined.