On Jun 10, 1:17 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > If we are going to work on this we may as well solve a different > problem. > > Executing models take time. If you have 500 tables each defined it its > own file, it takes lots of time. Yet not all actions need all tables > so we may want to implement a dependency not just among models but > among actions and models so that not-needed models are not executed. > > If the dependencies are expressed in the model files themselves they
... I assume you meant to say "...in controller files..." > still needs to be executed (or at least bytceode compiled) to be > resolved and that defies the purpose. > Moreover this would be similar to the python import mechanism (from a > user prospective) and thus an example of reinventing the wheel. ... if I am following you, then why do we not just import the needed models? I mean, really, seriously - why the need to exec? It seems like that is a question on the table. > > Having a centralized place where these dependencies are expressed has > advantages: > - sets us a apart from everybody and we do not need to reinvent the > wheel Global variables in FORTRAN had proponents too - but the need to manage complexity drove a different structure in programming. (That is to say, I am not seeing, am challenging that there are _any_ REAL advantages to centralized dependency management;) ==> "set us apart" is not any kind of advantage, if it does not provide tangible benefit. (that is, benefit may drive what sets web2py apart, but making "set apart" a motive is not beneficial in and of itself - this should be very clear). If there is a current wheel that is useful, use it. $ python >>> import this one way is better; if there is something that currently solves the problem, use it (don't 'reinvent the wheel'; _and_ don't look for problems as an excuse to invent a wheel) > - it will make the structure of the application easier to read in a > single place ... I don't agree, don't see this as beneficial; harder to maintain; related information scattered; > - it will make the app faster ... this is not a benefit - it is a goal; you are implying that centralized models are the only way to make an app faster; I'm not buying; I don't think that's true at all. > - it will be easier to implement without breaking backward > compatibility (and there it will get done) .... simplicity of implementation is a benefit to _you_; but (while that may be important to you), simplicity to implement applications (since it happens more frequently) is first in line; _then_ simplicity of implementation, practicality; .... I don't see this as a benefit of central place; > - it will open the possibility for dependencies to be auto-discovered > and therefore the config-file auto-generated ... actually, you could generate (if that were the most practical way) a central dependency list from local declarations (which is how Windows Registry works); I don't see this is a benefit of "central place", rather a practical consideration. ... this is beginning to feel like an old tet-a-tet. > > ...
