If the request is simply to weigh in, then I've got some rhymes for the house.
Regarding the supposed Itcl compatibility of Tcl 8.6, having to invoke methods
in the same object with either $this or [self] is a non-starter for us
(FlightAware) -- we have way too much Itcl code for that plus it just smells.
Surely it's temporary.
Object systems let you build bigger programs without losing control of them. I
think it's a really natural idea -- code and data are defined together and you
can have multiple instances of something with all the data for each instance
nicely grouped and easily accessed. Upvar is heavily (ab)used as a sort of
pseudo-object system. Look at tcllib for lots of examples. For example with
the http package, code accesses instances of data using upvar. It works but
it's better to support it in a first order and non-kludgey way, i.e. built into
the language.
I think object-oriented typeless langauges (like Itcl, etc) work well. You
don't have to write different methods for all the possible datatypes like you
do for C++ or Objective C.
I know form can do GET and POST.
On Oct 27, 2010, at 8:34 PM, Damon Courtney wrote:
> Just jumping in here. I'm working pretty heavily in Rivet for the next few
> months, so I will be updating little things and making changes a lot. The
> form package is due for some updating and a bit of an overhaul, I think. I
> know that Karl said they have a version that returns the form elements
> instead of outputting them, and that's probably a good change.
>
> As far as I know, passing -method should accept anything. There's not an
> actual check on what is supported, and what is supported in the form tag is
> up to your browser. I know I ran into this recently. I would do something
> like:
>
> form #auto -method PUT
>
> And in viewing the source, it would say method="PUT", but when it was
> submitted back to the server, PUT had been turned to POST (POST is the
> default, by the way). After some reading, I think this was the browser doing
> it. I couldn't find a better explanation. So, I was trying to figure out
> how the Rails guys do it since they use PUT and DELETE as methods in their
> RESTful interfaces. Turns out they fake it. They just include a hidden
> field that passes the method, and the Rails code on the backend knows to look
> for this variable and set the method to that. So, I went with that. 0-]
>
> I think all of our packages should be converted to TclOO if we can. Though
> the latest Itcl IS built on top of TclOO, so we're really just talking syntax
> here. I don't particularly care as long as we're talking TclOO in the
> future. I'm all for moving things forward to 8.6 with a newer version. Not
> necessarily dropping support for 8.5, just using 8.6 where we can. That
> would be one advantage to using Itcl syntax. It remains backward compatible
> with 8.5 and the old Itcl.
>
> Anyone else wanna' weigh in here? 0-]
>
> D
>
>
> On Oct 27, 2010, at 7:16 PM, Clif Flynt wrote:
>
>> On Thu, Oct 28, 2010 at 12:38:29AM +0100, Massimo Manghi wrote:
>>>
>>> wouldn't '$this methodName' work out a solution?
>>
>> I won't swear to it, but I think I tried that first, and 'my cmd',
>> and neither of them was happy with me.
>>
>>>> I've got a kludged version of form.tcl that works (to the extent
>>>> that I've tested it) with the new 8.6.
>>>>
>>>> Is anyone interested in this code?
>>>>
>>>
>>> yes, I am.
>>
>> I've attached it to this email. If attachments get scrubbed, let
>> me know, and I'll mail it direct.
>>
>>> It's something we should talk about. Tcl 8.6 is getting momentum among the
>>> Tcl'ers and its new introductions will probably set new standards in the
>>> language history.
>>
>> I'm pretty bullish on TclOO. I think it's a nice mix of providing
>> structure while still giving the developer the freedom to rework
>> things as his understanding of the problem matures. (How's that for
>> buzz-word compliance?)
>>
>> I worked in C++ for 5 or 6 years and did a little with itcl. I ended
>> up unthrilled with OO. TclOO has revived my excitement.
>>
>> This construct in the form.tcl code was the only one that caused
>> me some dismay at a quick-N-dirty translation to TclOO:
>>
>> public variable defaults "" {
>> upvar 1 $defaults array
>> array set DefaultValues [array get array]
>> }
>>
>> I think this can be implemented in TclOO with a variable trace and a
>> new object method, but I didn't have time right then to play with it.
>>
>> Clif
>>
>> --
>> ... Clif Flynt ... http://www.cwflynt.com ... [email protected] ...
>> .. Tcl/Tk: A Developer's Guide (2nd edition) - Morgan Kauffman ..
>> .. 17'th Annual Tcl/Tk Conference: 2010, Oak Brook, IL USA ..
>> ............. http://www.tcl.tk/community/tcl2010/ ............
>>
>>
>>
>>
>>
>> <form8.6.tcl>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
