You will not agree with my comments below. Apparently, we cannot even agree on what happened in the discussion. However, my concepts became clearer, at the least for me, in this discussion and you pointed out ways to do things that can be useful. So, I am thankful for all the time that you spent here. It's very much appreciated.
On Friday, 24 June 2016 08:27:04 UTC-4, Anthony wrote: > > > This discussion is challenging and it shows that you are right that use >> cases are useful, if only to help frame a discussion. I think that your use >> case is not to pass the configuration information, but the need for a >> wrapper (for pre-processing and post-processing) >> > > No, that is *your* use case/requirement. You began this whole discussion > with the idea of passing configuration information but claimed what you > really cared about was a "wrapper application." > I was aware of that and I can see what happened in your mind - it's OK, but very early I explained that the notion of application wrapper was defined in response to a use case where we want to pass configuration information under severe constraints, which included the extra requirement. So, the definition of application wrapper included the extra requirement, first implicitly, but as soon as needed, it was added explicitly with a strong emphasis. So, this use case without the extra requirement is definitively not mine. It is yours. I am not trying to diminish you or to fight with you, but I know what was my use case, please. > I provided several very simple solutions for passing configuration > information that did not entail "wrapping" the application, but you balked > at those options, claiming what you really wanted was a way to "wrap" > applications. > Because I used this notion of wrapper to pass the extra requirement. You made me realize that one can see the notion of wrapper differently, only in terms of pre-processing and post-processing, without the extra requirement. I acknowledged quite early in the discussion, as soon as I realized it, that this could be interesting, but not my use case in this thread. In fact, I consider this as one of your contribution in this thread. You made me realize that we should define carefully the notion of application wrapper. I asked that we adopt the definition that includes the extra requirement and I am still asking this. In a community, it's nice to have common definitions. However, fight on definitions are not productive. It has to happen naturally. > So, I have obliged and attempted to identify possible solutions for you. > Now you seem to be backtracking and claiming you really only care about > passing configuration information, which is a very specific use case. > Not at all, but it might be what you personally experienced. > That's fine, but don't make it sound like I'm trying to push the idea of a > wrapper -- that has always been your requirement. Please go back and > re-read your own writing. > Not interested. I remember the main flow. One might find some isolated sentences where the extra requirement was ignored, because I was not yet fully aware that it was important to clearly mention it. However, globally, it's clear that very early I defined application wrapper with the extra requirement. > >> Moreover, we do not even agree on what are valid use cases. You insist >> that use cases should be real world use cases, >> > perhaps even consider that a use case has to come from the real world by >> definition. I have the different view point that real world use cases are >> important, but not enough and that abstract use cases are necessary if we >> want to do development, I even think that the more we have a large scope, >> such as creating a new approach to web programming, even more general than >> a new language, the more we need abstract use cases. >> > > You make it sound as if I have made general proclamations about the nature > of innovation. We have not been having a discussion about abstract concepts > related to new programming paradigms -- we have been discussing a very > specific and concrete issue, namely the means by which you might do some > pre/post-processing of requests. > I was referring to the fact that, at many occasions, you explained that, if a requirement does not have a real-world use case, it is unimportant. I admit that it's me that brought in the notion of innovation to explain the usefulness of abstract use cases. > in web2py. My mention of "use cases" and "requirements" is limited to that > context. > Yes, I understood that. This is why, at one or two occasions, I asked that we think in terms of forking web2py and, in this way, consider that we are not in web2py anymore when we consider requirements. > My point is that web2py seems to be able to satisfy the *use cases* you > articulate (and probably many other related use cases) but not necessarily > some seemingly unnecessary *requirements*. > I certainly understood that it was your point. This is why I say that it is your use case. > I simply argue that it is not worth putting in significant effort to meet > those seemingly unnecessary requirements unless you can make a compelling > case that those requirements are necessary and that the effort to meet them > would be worth the benefit. You have not done so, nor even attempted to do > so. You seem to think that merely by declaring a concept "abstract," it is > necessarily important and therefore worth pursuing. > Read my last post again. I explain that the reason we use abstract use cases, without motivating them with real-world use cases, only motivating them as a way to frame a discussion, it's because it's the best we can do in a development process. > > Furthermore, as already noted, "real world" does not mean "currently > existing." > > In my last post, I covered that. In the analogy, it's the notion of abstract car. It's an abstract representation of the (true) real-world. BTW, perhaps you should revise your definition of "real world". > In the last post, I did not try to evaluate your __wrapper.py example. in >> terms of your use case or goal, which was to provide a wrapper for >> pre-processing and post-processing. I tried to make a point in terms of the >> use case that I stated originally, which was a need to pass the config >> information under severe constraints. I never claimed that I had a >> different way to do a wrapper application that fulfill your goal. >> > > Here is a quote from you (in response to the __wrapper.py idea): > > *However, if your objective is to be able to pass the configuration > information and the installer can use the application folder, I don't see > why they would not use it to achieve this objective, no need for a wrapper.* > > In other words, you were claiming that the installer could somehow "use > the application folder" to pass configuration information in a manner that > was different from the __wrapper.py idea. > There was a "if" at the beginning of the sentence. You have to understand the limited scope created by a "if". In French, we have the expression, "With a if, we can put Paris in a bottle." > Also, note that I never said the __wrapper.py method was a good solution > for merely passing configuration information > I never said or thought that you said that. Still, I wanted to say, if the objective was as in my use case, your proposal is an overkill. Note that I was aware that I did not mention the constraints in that sentence, because I explicitly only wanted to refer to this objective. However, I did restate the existence of these constraints in the next sentence, which you did not quote. -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
