[REBOL] Re: [ A world of words ] naming convention, namespace, namespace poll
From: nitsch-lists:netcologne at: 5-Jun-2003 1:04
Hi Marc, Gregg,
My favorite style-example is vid.
Its large, but lots smaller than comparable gui-toolkits.
And Carl tries to avoid accessor-functions there.
trying vid-style, i would use an interface like
tank/duration: 00:00:05
tank/rate: 5 ; liters
flow tank
if one wants really to access tank/content directly, in vid he could.
some times usefull, most time why?
-Volker
Gregg Irwin wrote:
>Hi Marc,
>
>MM> Unfortunately there is a small mistyping (the ":")
>
>Thanks for catching that! I'm not always as careful as I should be
>when responding to ML items; I go too fast and think too little. :)
>
>Thanks also for your detailed response. Now I can see clearly the
>issue we're up against, with the USE context being shared between
>instances. I thought about it for a little bit, and didn't come up
>with any brilliant solutions. While it might be possible to cook one
>up, it would likely obscure the main point and cause confusion if used
>as a teaching tool.
>
>So, I started on my real work for the day, but it nagged me, and then
>an idea began to grow in my mind. Given that REBOLs approach to OO
>concepts is different from the norm, should we really try to force fit
>standard examples into it? Maybe not. If students need to learn Java,
>C++, or .NET rules about how OO works in those enivirons, how valuable
>is it to see examples in REBOL. In other words, the OO concepts can be
>pure, but the implementations are not. In that light, how valuable is
>it to be able to see those concepts in action? I place a high value on
>that kind of thing myself, but there is a mismatch. If you create an
>articfical environment for demonstrating OO concepts, it doesn't
>really matter how it works behind the scenes, or if the language used
>is useful for other things (i.e. in the real world) versus being used
>*only* to explain and demonstrate OO concepts. What I'm talking about,
>of course, is building a dialect in REBOL which would be used to
>explain and demonstrate OO concepts as clearly as possible, without
>any particular regard for practicality.
>
>But I digress...
>
>MM> ;;;;;;;;;;;;; WHAT I WANT... THE "TANK" EXAMPLE
>
>Rather than taking a traditional approach which, as I said, would
>probably end up being less than attractive, I decided to look at it in
>a different way; a REBOLish way.
>
>What we want, is to use abstraction and information hiding to our
>advantage. Where REBOL differs is how strict it is about enforcing
>some of these things. In your scenario of the horrible code we *may*
>write, REBOL doesn't offer us much protection in how it implements OOP
>concepts. So how do we elegantly provide encapsulation and
>abstraction? How about with a dialect?
>
>Using your comments as a guide, I put together a dialect based
>approach to the tank problem. I started out simple, but kept getting
>ideas and decided to play with them a bit. (code at end of message)
>
>This approach doesn't solve the problem of completely preventing
>people from doing bad things if they have access to the code and data
>structures used internally, but it does show that you can provide a
>public interface that only allows certain things to be done.
>
>The way results are returned is...different. As I worked, I wanted a
>way to see the results of a command in context, then I started
>thinking about messaging in a remote or asynchronus enivronment, and
>*real* messaging as opposed to just RPC. I'll have to play with the
>idea more, and think about how the grammar needs to be bi-directional;
>that is, the client side may want to parse the response it gets.
>
>In any case, let me know what you think. I have to go do some real
>work now! :\
>
>-- Gregg
>
>; Code below. Watch for wrap!
>
>REBOL []
>
>tank: make object! [content: 0 capacity: 100]
>
>tank-context: make object! [
> tanks: copy []
> results: copy []
>
> ; This FORMs all results, so numeric result may not want to use it.
> add-result: func [item] [append results reduce [reform item]]
>
> ; Dialect Rules
> rules: context [
> available:
> none
> ; Parsed data (using a trailing * to denote them)
> id*: amount*: word*:
> none
>
> gallons: ['gallons | 'gallon]
>
> tank-id: [
> opt 'tank set id* [issue! | integer!] (id*: to issue! id*)
> ]
>
> make-tank: [
> 'make tank-id opt [
> opt ['with 'a] 'capacity opt 'of
> set amount* integer! opt gallons
> ]
> (
> either find/skip tanks id* 2 [
> add-result ["tank" id* "already exists"]
> ][
> append tanks reduce [
> id* make tank compose [
> capacity: (either amount* [amount*][100])
> ]
> ]
> add-result ["tank" id* "added"]
> ]
> )
> ]
>
> destroy-tank: [
> 'destroy tank-id
> (
> either find/skip tanks id* 2 [
> remove/part find tanks id* 2
> add-result ["tank" id* "destroyed"]
> ][
> add-result [
> "tank" id* "didn't exist, so was not destroyed"
> ]
> ]
> )
> ]
>
> add: [
> 'add set amount* integer! opt gallons ['in | 'to] tank-id
> (
> available: tanks/:id*/capacity - tanks/:id*/content
> tanks/:id*/content: tanks/:id*/content + min amount*
available
> add-result [
> "Tank" id* "now contains" tanks/:id*/content "gallons"
> ]
> )
> ]
>
> subtract: [
> ; 'remove might be a better word than 'subtract
> 'subtract set amount* integer! opt gallons 'from tank-id
> (
> available: tanks/:id*/content
> tanks/:id*/content: tanks/:id*/content - min amount*
available
