Clarifying Modules & using

General
1

I’ve been out of the Xojo world for a while, but I’ve decided to rewrite my old OOP book for the new Xojo.

The most obvious OOP feature that’s been added in the last few years is using with modules.

The documentation is, as usual, incomplete on the issue. From what I can see when experimenting with the feature, if a class is set to using a Module, then all the methods, protected or public, on the module are available as if declared on the class in question, but the exact semantics appear to be… interesting.

If I declare a Class1 using a module Test, and I add Test.foo(extends c As Class1), then I can do

Dim c As New Class1
c.foo

From within a method on Class1, I can do just:

foo

and c gets transparently set to self. I can also call foo without the extends argument, and it still works, so this appears to be just cleverly picking up the extends argument when called from within a class that is using the module.

It seems that if I call a method defined on both Class1 and Test, then if I call that method from within code declared in Class1, I get CLass1’s version of the method. But if I call it from Test, even calling it on c from within foo, I get the version from the module.

This is all very interesting, and particularly useful in breaking up the features of a complex class so it’s not just enormous, or for sharing code between classes.

My question is: is this behavior specified somewhere? I will endeavor to provide detailed documentation of it in my book, but first I have to work out all the behavior for myself. :slight_smile:

2

I’m sorry, but you plan on writing a technical book on a subject you do not fully understand?

and nothing about what you just mentioned is unique to Xojo, but rather common features implemented in one way or another in almost every OOP oriented language currently in existance.

and by “last few years”… you mean the last 20 years or so… right? because that is at least as long as this concept has been in use.

3

Hi, Dave.

Thanks for the comments. I’ve clearly not explained myself adequately. I am quite familiar with the subject area of OOP in general, and of OOP in Xojo in particular. This is a rewrite of a book I published ooh, five or ten years ago for what was then REALbasic.

Since I wrote the original version, this use of Modules in Xojo is new. What I’m after is not any sort of general explanation of OOP or mixins, but specifically how this feature works in Xojo. The scope rules would be appear to be unusual, for one.

So I’m just asking if there is detailed information about how using works with Modules in Xojo.

4

The use of Modules is not new… it has been in every version of RealBasic/RealStudio/Xojo that I have used in the past 11 years, and every version of VB6 thru VB.NET that I used before that, and in Pascal, and a few other languages well before that.

You have Modules which are made up of Methods (aka SUB / Function in other languages), these methods may be Private ( accessible only by other Methods in the same Module, a Module may also contain Variables (Integers, Strings etc), and these too may be Private to the module, or public to the application.

There is also a CLASS, while it has a structure similar to a Module (in that it contains Methods and Variables), it usually represents an Object (either a custom object or a subclass of an existing class that inherits from the original but adds additional methods, properties or events)

But again, this is nothing “new”, these concepts have existed since the very first language that defined the concepts of “OOP”

So if you have been in the Real/Xojo world and were unaware of these things before now, then you missed 90% of the reason Xojo is an OOP language.

As to “detailed information”… try the techinical documentation that came with your Xojo install

5

They should have no effect on “scope”

Start simple with a using clause in a method

Say you want to use the new frameworks dictionary
Normally you’d write

Dim d As New Xojo.Core.Dictionary

But with a using clause you can shorthand things

Using Xojo.Core
Dim d As New Dictionary

and “Dictionary” means “Xojo.Core.Dictionary”

At the level of a module this behaves the same.
The entire module can use the new framework as though declarations included what the is in the Using clause without having to fully qualify them.

And you can apply this to your own modules (namespaces)

The behaviour you’re seeing about which method is called should be completely unaffected by the use of Using

6

What was the title of your previous book ? I am sorry, but your name is not quite familiar to me.

Is it this : https://s3.amazonaws.com/engrade-myfiles/4083800423509935/RBCurriculumProject.pdf

I like the implementation of Eliza. It has been my pet program since AppleSoft Basic and I have translated it in all languages I touched since, including of course RB. I did not know this had been already done. In our age of bots, it is nice to see their grand grand mother :wink:

That said, any book about Xojo is an excellent idea.

7

If all authors mastered their subject before doing research, there would be nothing published. Not all books are doctoral thesis.

Eons ago I have written several technical books, and I did not “fully understand” the subject before starting to write. But the main skill of technical authors is not to know everything. Rather, it is to be able to research and then make the subject available to the reader. At least, that was how the whole publishing industry used to work…

8

My previous book was Object Oriented Programming with REALbasic.

I am particularly interested in using Modules as mixins. So you don’t wind up with your User class having 8,000 methods on it, and so you can share code between classes. The behavior I’ve observed shows that adding a using clause to a class does more than just bring the methods on the class into scope.

For example, if I have Class1 with a method DoIt, and a module Test with a method foo(extends c As Class1), I can, from within a method on Class1, call just foo and it works. So the using declaration does more than just bring foo into scope. If that was the case, I would have to do self.foo and I don’t.

But it’s not just working like a mixin would in, say, Ruby. The method search path seems to depend on where I start. So if Class1 and Test both have a method bar, if I call bar from within Class1, I get its bar and if I call it from Test I get its bar, so the mixin behavior is not entirely standard. I can just poke at this and try to work out all the permutations, but I’d prefer to get a definitive declaration of what the behavior is so I can be reasonably certain I haven’t missed anything.

9

No
It makes “foo” behave as though its part of the class and usable by just using “Foo”
Thats exactly whats meant by the documentation when it says “Makes all of the public declarations in a module (or namespace) available for inside the scope of the code as if it were defined there.”
They behave as if they are defined IN Class1 which does not require self.foo to invoke a method defined IN the class

It doesn’t change “scoping”
It DOES alter “name resolution”

10

There is at least a little more to it than that.

[code]Module Test
foo(extends x As Class1)
MsgBox “Foo”

Class Class1
using Test
DoIt
foo[/code]

foo has to be called on an instance of Class1. Nevertheless, I can do

Dim c As New Class1 c.DoIt
which results in foo receiving c in x. This is more than just letting me call methods on Test without prefixing them.

11

Also “Makes all of the public declarations in a module (or namespace) available for inside the scope of the code as if it were defined there” isn’t right either, as I’ve verified that protected methods of a module are available from within a class they are mixed into.

12
  1. you usually dont mix in something that also extends the class - so you’re starting with an odd usage pattern
  2. and IF you do mix in a module with methods that extend that class that you’ve mixed in TO what else would you expect to get in X - it HAS to be “self” basically - X MUST get some instance and that would be self in this usage

Normally with your code as follows (without the using) you would write

Module Test
  sub foo(extends x As Class1)
     MsgBox "Foo"
  end sub
end module

Class Class1
  Sub DoIt()
   self.foo
 end sub
end class

and the parameter X in foo gets “self”

Using can alter symbol resolution
And in this case it behaves more like you actually added all the methods from the module right into the Class - but its not literally doing that (extends is obviously handled specially as its not literally a copy of the methods in any event)

So things behave like the following

Module Test
  sub foo(extends x As Class1)
     MsgBox "Foo"
  end sub
end module

Class Class1
  Using Test // imagine you inserted ALL the methods from TEST here
  Sub DoIt()
      foo // <<<<< this still gets called like "self.foo"
 end sub
end class

Thats what you’re seeing

However I would not normally expect that you;d mix in a module that extended the class you’re mixing it into

13

I’m writing a book about OOP in Xojo, so I want to document all of the important behaviors, and also describe preferred design patterns. This undocumented behavior of Extends when combined with uses is both, I think, insofar as Xojo has mixins!. I would rather find some proper documentation for the feature rather than just try to sort it all out myself, is all.

14

Bought it years ago. Was an excellent introduction to OOP in REALbasic.

15

Likewise. There wasn’t much like it at the time.

16

11/12/2008 - Still have the receipt. Good to see you back Guyren