On Thu, Oct 22, 2009 at 10:54 AM, mdipierro <[email protected]> wrote:
> > Yarko, at least send us a document explaining how you think this > should work. An example of API, an example of admin interaction with > plugins. > NO, actually I want you to specify what you want (it's your project) - I am just reviewing and telling you what doesn't look like it fits, or is incongruent, will not work well, or will work counter to your stated objectives (If I define it, it will be my plugin, and I have other priorities now). As for API - that would be the last stage of design (boundaries, exposures, responsibilities, data rules) prior to starting coding (e.g. agile or otherwise).... I think you are still a long way from there - still no crisp concepts or abstraction of what you are talking about building. I can help you with processes of how to get there (e.g. your list of 13 - organize them, and then we can talk about why throwing out the parts where a plugin changes app tables is appropriate - those need to be recast to where an app only changes its tables, but asks a plugin to act on that data, and that will be a bit sticky even that encapsulated). > My major concern is not encapsulation but quite the opposite. My major > concern is not to constrain the developers too much before users start > experimenting with it. > If you do not want encapsulation, you will violate some major, fundamental cs principles that are very long standing (too many accessors to data create hard to trace bugs - there should be clear responsibilities for data items). > Consider Python. Classes do not have private methods but people follow > a convention that things starting with _ should not be called outside > the class itself. > Private methods or not, an API says what you _should_ call; hell, Microsoft office has unpublised functions that people call, but it's not "exposed" - not supported, so if you do that your on your own. You need to define boundaries, or you have no system (just random chaos). So - I gave my input. You seem to argue (now) on semantics that are not relavant. Of course you can say "I can read a db, and find out what the tables are so I will change them if I want; you can't stop me" ---- this is not evidence of "lack of encapsulation", merely evidence of hacking. If you publish an API, then you state your intention: "You can use this, and expect these results given these preconditions". First and foremost, putting code called plugin_[pluginname].py mixed in with an app is tantamount to publishing an api, and saying "oh - here's the _function(), and did I forget to say often enough you shouldn't use it?" Think of all the times you encourage people on web2py list (even with your statement above about "...names starting with _ we agree to not use") to use names starting with _, and how to appropriately use them.... ugh! I am very against the layout (plugin_[pluginname].py) you have proposed. I think that is a bad start. Of course, just like with ignoring convention on _ starting names, you can do that if you want. I expect it will produce ensuing problems, but is you insist on just doing it your way, I will watch for the outcome, and give you a post-mortem analysis (rather than this ahead of time warning and guidance), if you want. - Yarko > Massimo > > On Oct 22, 10:43 am, Yarko Tymciurak <[email protected]> > wrote: > > On Thu, Oct 22, 2009 at 7:02 AM, villas <[email protected]> wrote: > > > > > On Oct 21, 10:45 pm, mdipierro <[email protected]> wrote: > > > > We can go on and on. We need other people input on this. > > > > > I cannot understand why Massimo's plugin idea appears so contentious. > > > > The contention is on its congruence with its intent; this should not be > hard > > to understand. > > It intends to provide a "modular" system, but yet forces view of the > code > > into the appication space - this is asking for trouble (and has > unnecessary > > other limitations to boot). > > > > > Perhaps the only problem is that the smaller details of his > > > implementation are in his head rather than written down. > > > > Not at all - in fact, I suspect quite the contrary (and have tested / > > challenged that here): I believe the BIG details (never mind the small > ones) > > are not well worked out - in head or otherwise, and that is precisely > what I > > am saying this (in particular) needs BEFORE the "agile" build often / > > release often... you can't build much if you are either building the > wrong > > thing, or are unclear about important parts of what you are building. > > > > Agile is just a method for the very last steps of development (that is, > the > > implementation); scrums and stories are for relatively simple > requirements; > > this needs some responsibility-driven partitioning before you even start > > considering stuff down at the level that agile works. > > > > However, in > > > > > the best traditions of agile programming, he has released his concept > > > as software which can be tried and tested. What is the point of > > > pretending that we are working as a huge team of programmers who feel > > > compelled to specify their entire day before they can eat breakfast? > > > > > IMO there is little harm in adding a model, controller and views to an > > > app, providing they are named as per the convention and thus can > > > easily be removed again. > > > > I disagree - I disagree very strongly, for many reasons (separation of > > concerns; multiple responsibilities for data - a bane in programming > > recognized since the profusion of globals in Fortran drove people to > write > > RATFOR (rational fortran, a structure reminiscent of C, when C was not > yet > > widely available). > > > > THere are many fundamental and longstanding CS basics at risk here, and > > those basics have good reasons. That is being missed here, and needs to > be > > "seen" and appropriately dealt with. > > > > Agile of bad / imprecise requirements only results in quickly produced > bad > > results. > > > > I can understand if you don't see this, but that does not mean all these > > reasons are not here. > > > > So, I'll repeat: this needs work if it is to be workable and usable. Of > > this I have no doubts. > > > > - Yarko > > > > > > > > > If people are confusing the presence of a few extra files in their > > > directories as spaghetti code, they are surely mistaken. There is no > > > reason to have all the files in one directory if there is an install > > > and uninstall procedure. For example, if all models, including those > > > of the plugin, can be found in one place, then surely that's > > > beneficial. > > > > > I vote that we should embrace Massimo's idea and encourage him. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
