Re: OOP in Rev...
1) Lack of experience 2) Concern about performance - I'm working on an audio application which can get into some intensive processing. It seems that the object template stack or what JB suggested below is the consensus choice of the group so I'll start there. Thanks to everyone that made suggestions. len morgan jbv wrote: what hinders you from having a function crateFader that would dynamically build a group with all the required components ? No need to store any object, just call the function as many times as needed... Best, JB ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: OOP in Rev...
Viktoras, you can effectively hide the array manipulations in a library stack. I've done this quite a lot, though haven't really thought of it as OOP-like, though it produces at least some kind of 'encapsulation'. One could think of the library stack as being the place where you define 'classes'. Just off the top of my head, the script of the library 'class' stack might look like this : local sCities local sCityProperties = country,continent,population,area,isNationalCapital,hasAirport on setCity pCity, pProp, pVal if pProp is among the items of sCityProperties then put pVal into sCities[pCity, pProp] end setCity function getCity pCity, pProp if pProp is empty then put all into pProp switch pProp case all return allCityData(pCity) break case populationDensity return popDensity(pCity) break default return sCities[pCity, pProp] break end switch end getCity function allCityData pCity put the keys of sCities into tKeys filter tKeys with pCity * repeat for each line L in tKeys put item 2 of L = sCities[L] cr after tCityData end repeat put popDensity(pCity) after tCityData return tCityData end allCityData function popDensity pCity return sCities[pCity, population] / sCities[pCity, area] end popDensity and so-on so then in the main app, you'd do things like : setCity London, country, UK setCity London, population, 800 if getCity(London, populationDensity) 34 then put getCity(London) which is sort of equivalent to : London.population = 800 if London.populationDensity 34 then Forgive me if this is all stuff you've already done, but it's certainly helped me think about it a bit! Best, Mark On 19 Mar 2008, at 14:19, viktoras didziulis wrote: Hi, me too like rOOP, but I feel it is a little incomplete, just one more step. The ones that you call real objects are limited to user interface controls only. The thing I was curious about is a possibility to create an independent data object which is nor control neither a gui element. Which in this case may simply mean enhanced arrays... What for ?. I think this would make code cleaner and reduce amount of commenting in larger projects.. Also facilitate creation or adoptions of existing libraries in C or C++ for very specific purposes - like reading shapefiles, netcdfs, doing geographical transformations, astronomy, bioinformatics, etc... This consequently will increase the scope of applications that can be created in Rev and hopefully availability of diverse libraries. In general it would make creation of complex software easier. We can already simulate objects using arrays, but at least the code would be more readable (!!!) if I were able to distinguish array operations from object manipulations. Best wishes Viktoras Mark Schonewille wrote: Hi, I just don't get it. I never ever felt a need for OOP and I just can't imagine I ever will, using xTalks. I'd call xTalk rOOP (really object oriented programming) because xTalk uses real objects, like fields, buttons, etc. Why don't you simply forget about OOP? What does OOP have that rOOP doesn't? Mark -- Economy-x-Talk Consultancy and Software Engineering http://economy-x-talk.com http://www.salery.biz Get your store on-line within minutes with Salery Web Store software. Download at http://www.salery.biz Op 19-mrt-2008, om 13:25 heeft viktoras didziulis het volgende geschreven: I would like to define a class, an object (the both with their properties) and methods that are not a part of graphical user interface or Revolution engine... ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: OOP in Rev...
On Mar 19, 2008, at 8:25 AM, viktoras didziulis wrote: I would like to define a class, an object (the both with their properties) and methods that are not a part of graphical user interface or Revolution engine... Let's say I need an object City having properties: minLatitude, maxLatitude, minLongitude, maxLongitude, area, populationSize, growthRate, dateFounded, currentDate so it can be handled using specific handlers and functions (e.g. its methods). Or, well, it would be more correct to start with creation of a class City or templateCity and then use it to create new city objects (NewYork, Paris, etc...) that can be processed by their functions like populationGrowth(Paris, start_year, end_year) and so on... The three approaches that I can imagine are somehow inter-tangled: (1) creating an object as a custom property set of a stack or (2) creating it as an array or (3) creating it as an invisible control with custom properties. But all these have their drawbacks. Just some quick notes from methods I've tried. You probably won't find any consensus on this since Rev does not have an elegant way of extending the xtalk syntax to our own custom objects. Hopefully one day... 1) This could work but I have found it easier to work with individual objects. I just pass button references around to my class handlers. See point 3 notes. 2) This can be useful in some circumstances but it is easier to inspect the custom props of a button during debugging. 3) I prefer this approach. I create a stack that I use as a library. I then create classes using handler prefixes: put city.getProp (pLongIDofButton, growth rate) into theGrowthRate city.setProp pLongIDofButton, growth rate, 1 put city.Serialize (pLongIDofButton) into theSerializedCity Each handler takes a reference to a button whose uObjectProps custom property set represent the object properties. So calling city.getProp would return the uObjectProps[growth rate] custom property for example. Calling city.setProp would set the uObjectProps[growth rate] value after having performed integrity checks. I create buttons on hidden stacks or just hide the button itself on a visible stack. Depends on my needs. I prefer to define city.getProp/setProp handlers since I hate writing out city.getGrowthRate, city.setGrowthRate every time I want to add a new property. I never use Revolution's getProp/setProp handlers when dealing with custom objects unless they are GUI elements. getProp/setProp fails to be called when messages are locked which is not very robust. The (1) and (3) approach allows attaching handlers to custom properties and allows accessing object (e.g. a custom property set) properties using both an array notation (somehow an equivalent to an array-like behavior of objects in javascript) and in a way consistent with handling of properties in Rev e.g. set the .. of .. to ... or get .. the .. of Unfortunately (1) allows only a single object to be active and thus accessible. The (3) is a dirty one, because object is created using empty controls with their own additional properties and methods. The (2) looks promising, one can create a class, write a constructor function that would create new objects from the class, etc... But it lacks consistency with the existing OOP style in Rev - e.g. you can not get or set an element of an array using get the element/property of array/object or set the element/property of array/object to value. Besides you can not use getProp or setProp handlers with array's elements. Not being able to define our own objects that have the same elegant syntax that is native to Rev is the real drawback. Did anyone try doing something like this kind of OOP in Rev? I would appreciate if you can share your thoughts, warnings, tricks and approaches :-). I am not looking for a complex C++ like style of OOP in Rev. Anything simpler like the OOP model of javascript would be OK. In general, I think, it would be nice if one could treat and access Revolution arrays as objects with custom properties, with all the getProp, setProp and templateObject stuff... Or is it possible somehow? If not, is this already posted to QC as an enhancement request - I would vote for it? Otherwise going to post it there myself... Just some thoughts. I have tried a few different approaches myself and the above is what I have settled on for the time being. Regards, -- Trevor DeVore Blue Mango Learning Systems www.bluemangolearning.com-www.screensteps.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
OOP in Rev...
I would like to define a class, an object (the both with their properties) and methods that are not a part of graphical user interface or Revolution engine... Let's say I need an object City having properties: minLatitude, maxLatitude, minLongitude, maxLongitude, area, populationSize, growthRate, dateFounded, currentDate so it can be handled using specific handlers and functions (e.g. its methods). Or, well, it would be more correct to start with creation of a class City or templateCity and then use it to create new city objects (NewYork, Paris, etc...) that can be processed by their functions like populationGrowth(Paris, start_year, end_year) and so on... The three approaches that I can imagine are somehow inter-tangled: (1) creating an object as a custom property set of a stack or (2) creating it as an array or (3) creating it as an invisible control with custom properties. But all these have their drawbacks. The (1) and (3) approach allows attaching handlers to custom properties and allows accessing object (e.g. a custom property set) properties using both an array notation (somehow an equivalent to an array-like behavior of objects in javascript) and in a way consistent with handling of properties in Rev e.g. set the .. of .. to ... or get .. the .. of Unfortunately (1) allows only a single object to be active and thus accessible. The (3) is a dirty one, because object is created using empty controls with their own additional properties and methods. The (2) looks promising, one can create a class, write a constructor function that would create new objects from the class, etc... But it lacks consistency with the existing OOP style in Rev - e.g. you can not get or set an element of an array using get the element/property of array/object or set the element/property of array/object to value. Besides you can not use getProp or setProp handlers with array's elements. Did anyone try doing something like this kind of OOP in Rev? I would appreciate if you can share your thoughts, warnings, tricks and approaches :-). I am not looking for a complex C++ like style of OOP in Rev. Anything simpler like the OOP model of javascript would be OK. In general, I think, it would be nice if one could treat and access Revolution arrays as objects with custom properties, with all the getProp, setProp and templateObject stuff... Or is it possible somehow? If not, is this already posted to QC as an enhancement request - I would vote for it? Otherwise going to post it there myself... All the best! Viktoras ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: OOP in Rev...
Hi, I just don't get it. I never ever felt a need for OOP and I just can't imagine I ever will, using xTalks. I'd call xTalk rOOP (really object oriented programming) because xTalk uses real objects, like fields, buttons, etc. Why don't you simply forget about OOP? What does OOP have that rOOP doesn't? Mark -- Economy-x-Talk Consultancy and Software Engineering http://economy-x-talk.com http://www.salery.biz Get your store on-line within minutes with Salery Web Store software. Download at http://www.salery.biz Op 19-mrt-2008, om 13:25 heeft viktoras didziulis het volgende geschreven: I would like to define a class, an object (the both with their properties) and methods that are not a part of graphical user interface or Revolution engine... ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: OOP in Rev...
Viktoras, I have not tried this in Rev but I was thinking that you might want to mix the array with custom props so that the array set the custom props of the object. The array could build the object and it's properties. Just a thought. Others on the list will have more experience with this. Tom On Mar 19, 2008, at 8:25 AM, viktoras didziulis wrote: I would like to define a class, an object (the both with their properties) and methods that are not a part of graphical user interface or Revolution engine... Let's say I need an object City having properties: minLatitude, maxLatitude, minLongitude, maxLongitude, area, populationSize, growthRate, dateFounded, currentDate so it can be handled using specific handlers and functions (e.g. its methods). Or, well, it would be more correct to start with creation of a class City or templateCity and then use it to create new city objects (NewYork, Paris, etc...) that can be processed by their functions like populationGrowth(Paris, start_year, end_year) and so on... The three approaches that I can imagine are somehow inter-tangled: (1) creating an object as a custom property set of a stack or (2) creating it as an array or (3) creating it as an invisible control with custom properties. But all these have their drawbacks. The (1) and (3) approach allows attaching handlers to custom properties and allows accessing object (e.g. a custom property set) properties using both an array notation (somehow an equivalent to an array-like behavior of objects in javascript) and in a way consistent with handling of properties in Rev e.g. set the .. of .. to ... or get .. the .. of Unfortunately (1) allows only a single object to be active and thus accessible. The (3) is a dirty one, because object is created using empty controls with their own additional properties and methods. The (2) looks promising, one can create a class, write a constructor function that would create new objects from the class, etc... But it lacks consistency with the existing OOP style in Rev - e.g. you can not get or set an element of an array using get the element/property of array/object or set the element/property of array/object to value. Besides you can not use getProp or setProp handlers with array's elements. Did anyone try doing something like this kind of OOP in Rev? I would appreciate if you can share your thoughts, warnings, tricks and approaches :-). I am not looking for a complex C++ like style of OOP in Rev. Anything simpler like the OOP model of javascript would be OK. In general, I think, it would be nice if one could treat and access Revolution arrays as objects with custom properties, with all the getProp, setProp and templateObject stuff... Or is it possible somehow? If not, is this already posted to QC as an enhancement request - I would vote for it? Otherwise going to post it there myself... All the best! Viktoras ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: OOP in Rev...
Putting the OOP vs rOOP discussion aside for a moment, I would love to have the ability to create new GUI objects. For example, consider a fader for a mixing board. It has a sliding thumb (like a scrollbar), usually a pan control at the top, perhaps a VU meter next to the slider to show the signal (sort of a progress bar), and a couple of text fields at the bottom for the name of the channel (Guitar, Vocal, etc), and the current dB value of the slider. Such an object would have properties for current slider position, set the VU meter level, set the pan position, etc. I'd like to be able to create this object and place it on a card just like a button or field. I suppose this could be done with a group (just about all of the required pieces are there and could be manipulated with xTalk) but I don't know of an easy way to store that object in such a way that I could drop it on to a card. Perhaps a future enhancement might be stack format that could save just an object in it (.obj or .wid?). I don't think that would be too big a stretch. Any ideas or comments? len morgan Mark Schonewille wrote: Hi, I just don't get it. I never ever felt a need for OOP and I just can't imagine I ever will, using xTalks. I'd call xTalk rOOP (really object oriented programming) because xTalk uses real objects, like fields, buttons, etc. Why don't you simply forget about OOP? What does OOP have that rOOP doesn't? Mark -- Economy-x-Talk Consultancy and Software Engineering http://economy-x-talk.com http://www.salery.biz Get your store on-line within minutes with Salery Web Store software. Download at http://www.salery.biz Op 19-mrt-2008, om 13:25 heeft viktoras didziulis het volgende geschreven: I would like to define a class, an object (the both with their properties) and methods that are not a part of graphical user interface or Revolution engine... ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: OOP in Rev...
Hi Len, I make new objects all the time. I just combine the components in a group and when I need it, I copy the group, by script, from a template stack to its destination. Setprop handlers allow me to treat the group as if it were a true, native object. Best, Mark -- Economy-x-Talk Consultancy and Software Engineering http://economy-x-talk.com http://www.salery.biz Get your store on-line within minutes with Salery Web Store software. Download at http://www.salery.biz Op 19-mrt-2008, om 14:02 heeft Len Morgan het volgende geschreven: Putting the OOP vs rOOP discussion aside for a moment, I would love to have the ability to create new GUI objects. For example, consider a fader for a mixing board. It has a sliding thumb (like a scrollbar), usually a pan control at the top, perhaps a VU meter next to the slider to show the signal (sort of a progress bar), and a couple of text fields at the bottom for the name of the channel (Guitar, Vocal, etc), and the current dB value of the slider. Such an object would have properties for current slider position, set the VU meter level, set the pan position, etc. I'd like to be able to create this object and place it on a card just like a button or field. I suppose this could be done with a group (just about all of the required pieces are there and could be manipulated with xTalk) but I don't know of an easy way to store that object in such a way that I could drop it on to a card. Perhaps a future enhancement might be stack format that could save just an object in it (.obj or .wid?). I don't think that would be too big a stretch. Any ideas or comments? len morgan ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: OOP in Rev...
Len Morgan a *crit : I suppose this could be done with a group (just about all of the required pieces are there and could be manipulated with xTalk) but I don't know of an easy way to store that object in such a way that I could drop it on to a card. Perhaps a future enhancement might be stack format that could save just an object in it (.obj or .wid?). I don't think that would be too big a stretch. what hinders you from having a function crateFader that would dynamically build a group with all the required components ? No need to store any object, just call the function as many times as needed... Best, JB ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: OOP in Rev...
Hi, me too like rOOP, but I feel it is a little incomplete, just one more step. The ones that you call real objects are limited to user interface controls only. The thing I was curious about is a possibility to create an independent data object which is nor control neither a gui element. Which in this case may simply mean enhanced arrays... What for ?. I think this would make code cleaner and reduce amount of commenting in larger projects.. Also facilitate creation or adoptions of existing libraries in C or C++ for very specific purposes - like reading shapefiles, netcdfs, doing geographical transformations, astronomy, bioinformatics, etc... This consequently will increase the scope of applications that can be created in Rev and hopefully availability of diverse libraries. In general it would make creation of complex software easier. We can already simulate objects using arrays, but at least the code would be more readable (!!!) if I were able to distinguish array operations from object manipulations. Best wishes Viktoras Mark Schonewille wrote: Hi, I just don't get it. I never ever felt a need for OOP and I just can't imagine I ever will, using xTalks. I'd call xTalk rOOP (really object oriented programming) because xTalk uses real objects, like fields, buttons, etc. Why don't you simply forget about OOP? What does OOP have that rOOP doesn't? Mark -- Economy-x-Talk Consultancy and Software Engineering http://economy-x-talk.com http://www.salery.biz Get your store on-line within minutes with Salery Web Store software. Download at http://www.salery.biz Op 19-mrt-2008, om 13:25 heeft viktoras didziulis het volgende geschreven: I would like to define a class, an object (the both with their properties) and methods that are not a part of graphical user interface or Revolution engine... ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: OOP in Rev...
Viktoras, The availability of OOP really doesn't affect the scope of applications. Nor does it affect the use of C++. You won't be able to use C++ anyway, you need to create externals for that, which you can do already. Last but not least, I can't think of any code more readable than Talk code. . Best regards, Mark Schonewille -- Economy-x-Talk Consulting and Software Engineering http://economy-x-talk.com http://www.salery.biz A large collection of scripts for HyperCard, Revolution, SuperCard and other programming languages can be found at http://runrev.info On 19 mrt 2008, at 15:19, viktoras didziulis wrote: Hi, me too like rOOP, but I feel it is a little incomplete, just one more step. The ones that you call real objects are limited to user interface controls only. The thing I was curious about is a possibility to create an independent data object which is nor control neither a gui element. Which in this case may simply mean enhanced arrays... What for ?. I think this would make code cleaner and reduce amount of commenting in larger projects.. Also facilitate creation or adoptions of existing libraries in C or C++ for very specific purposes - like reading shapefiles, netcdfs, doing geographical transformations, astronomy, bioinformatics, etc... This consequently will increase the scope of applications that can be created in Rev and hopefully availability of diverse libraries. In general it would make creation of complex software easier. We can already simulate objects using arrays, but at least the code would be more readable (!!!) if I were able to distinguish array operations from object manipulations. Best wishes Viktoras ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: OOP in Rev...
Len Morgan wrote: Putting the OOP vs rOOP discussion aside for a moment, I would love to have the ability to create new GUI objects. For example, consider a fader for a mixing board. It has a sliding thumb (like a scrollbar), usually a pan control at the top, perhaps a VU meter next to the slider to show the signal (sort of a progress bar), and a couple of text fields at the bottom for the name of the channel (Guitar, Vocal, etc), and the current dB value of the slider. Such an object would have properties for current slider position, set the VU meter level, set the pan position, etc. I'd like to be able to create this object and place it on a card just like a button or field. I suppose this could be done with a group (just about all of the required pieces are there and could be manipulated with xTalk) but I don't know of an easy way to store that object in such a way that I could drop it on to a card. Perhaps a future enhancement might be stack format that could save just an object in it (.obj or .wid?). I don't think that would be too big a stretch. Any ideas or comments? You could make a substack called ObjectTemplates and store your custom group widgets there. To get them on the current card, just use: copy grp MyWidget of stack ObjectTemplates to this cd The nice thing about that form of the copy command is that when you specify a destination the object goes directly there rather than to the clipboard, so the user's clipboard data is not affected. If you need a simpler form you could write a handler like this: on CreateCustom pObjectType copy grp pObjectType of stack ObjectTemplates to this cd end CreateCustom ...so when calling it you never need to remember where the template group object is locatated: CreateCustom MyWidget Ken and I have adopted a convention over the years of defining custom object types in a library, putting as little code as possible into the widget itself and instead having its UI elements call handlers in that library. This allows us to fix bugs and provide enhanced behaviors by working with just one script, and all instances of the object reflect the changes. The Rev Interoperability Project has produced a set of guidelines for making libraries and custom widgets which can be shared with others more easily by storing common metadata (type, copyright, version, etc.) in a set of custom props -- see the ECMI Spec (Edinburgh Core Metadata Initiative) in the Files section here: http://tech.groups.yahoo.com/group/revInterop/ For example, using the uRIP[type] property, a frontScript or library can easily identify the type of control, so system messages can be routed to specific handlers if needed, using simple in-the-path messaging rather than the slower send command: on mouseDown if the uRIP[type] of the target is Splitter then ufwSplitterMouseDown -- defined in a library else pass mouseDown end mouseDown We've had more than a dozen Rev developer contribute to the ECMI guideliness, and at this point they're complete enough that it's possible to make version control and auto-update tools that work on all ECMI-savvy components regardless of who made them. There are tools there now (RIPEdit and others) which make it easy to add RIP properties to a stack with a simple inspector tool. One downside to working with groups as custom controls is that they're inherently brittle during development; that is, it's really easy to turn on the selectGroupControls and accidentally move controls within the group. This RQQC request addresses this by proposing a new locked property for groups which would make them behave as a single control under the pointer tool, regardless of the state of the selectGroupControls global property: http://quality.runrev.com/qacenter/show_bug.cgi?id=2144 -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: OOP in Rev...
viktoras didziulis wrote: me too like rOOP, but I feel it is a little incomplete, just one more step. The ones that you call real objects are limited to user interface controls only. The thing I was curious about is a possibility to create an independent data object which is nor control neither a gui element. Which in this case may simply mean enhanced arrays... I believe Mark Waddingham has hinted in the past that adding OOP extensions to Rev would be an interesting thing to do. Even going back to when Scott Raney owned the engine, there were some ideas along these lines floating around -- see the bottom of this page: http://www.metacard.com/pi5.html Of course at this point there's no telling when such things may make it into the engine or what form they'll take, but at least it's encouraging that the notion appears to have the owners' interest. In the meantime, I've been getting by well enough adopting some of the philosophy behind the original Mac OS API to my work. Long before OOP became the standard, the Mac API was centered around Managers, with discrete components interoperating with others through minimal and well-defined connections. Much of that architectural style lends itself well to working with Rev, allowing us to get some of the benefits of OOP today without needing to wait for anything from RunRev. And down the road if/when they add OOP extensions to the language, so much the better. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: OOP in Rev...
Recently, Richard Gaskin wrote: This RQQC request addresses this by proposing a new locked property for groups which would make them behave as a single control under the pointer tool, regardless of the state of the selectGroupControls global property: http://quality.runrev.com/qacenter/show_bug.cgi?id=2144 Vote cast. Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: OOP in Rev...
this is the web page from which I started looking into MetaCard and finally came to Revolution website a few years ago. One more interesting thing Scot mentioned there is right before the paragraph about the completion of OO features where he wrote about possibility to output java bytecodes: A method for outputting Java byte-codes equivalent to MetaCard scripts has been designed, but implementation has been delayed until the serious performance, compatibility, and functionality limitations in Java have been rectified. Nice idea :-). Viktoras Richard Gaskin wrote: --- I believe Mark Waddingham has hinted in the past that adding OOP extensions to Rev would be an interesting thing to do. Even going back to when Scott Raney owned the engine, there were some ideas along these lines floating around -- see the bottom of this page: http://www.metacard.com/pi5.html --- ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
OOP in Rev
So how do the standard object-oriented programming concepts translate into the Rev world? How do I make classes, subclasses, instances, etc. Thanks, Mat --- Make a FREE food donation to hungry people around the world. http://www.thehungersite.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
