@env instance variable in Request class #408

ghost opened this Issue Jul 14, 2012 · 7 comments


None yet
2 participants

ghost commented Jul 14, 2012

When inheriting methods from Rack::Request,
base class have to declare @env instance variable for methods to work.

In some scenarios(as mine ones) that's not quite acceptable.

Any viable reason to use instance variable instead of method?
There already are an attr reader for env in Request class.
Does it make sense to make an pull request that will update Request class to use env method instead?


raggi commented Jul 15, 2012

Would you mind explaining your use case, I don't understand given that all you have to do is place an @ in front.


ghost commented Jul 15, 2012

Well, the base class has own @env instance variable, that should not interfere with Rack one.


lgierth commented Jul 15, 2012

-1, instance variables are part of the contract between the base class and the extending class. You can't override them without possibly breaking the contract.


ghost commented Jul 16, 2012

Yep :)
that's perfectly true when using Rack::Request as base class.

But when an arbitrary class inherits from Rack::Request, it inherits only the methods, not the contract itself,
cause base classes usually has own contracts.

It is annoying, i know :)
but this would help me(and maybe others) a lot, and wont affect Rack in any way.


lgierth commented Jul 16, 2012

The extending class of course also inherits the instance variables.

I don't understand why you would want an "arbitrary class" to inherit from Rack::Request. If it isn't strongly related (== same or very similar interface), you should rather encapsulate than inherit.


lgierth commented Jul 16, 2012

You might also want to have a look at the [SOLID principles](http://en.wikipedia.org/wiki/SOLID_(object-oriented_design\)), particularly at the Liskov substitution principle, which basically states that

objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.


ghost commented Jul 16, 2012

ok, giving up.
it's simpler to use another way than to argue this one :)

i realize Rack has well determined design and it should NOT be altered by occasional trifles.

@ghost ghost closed this Jul 16, 2012

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment