Basically I can not for the life of me figure out how to make an array that will allow me to manage/access class
I mean like
ClassArray(1) = new Class1
ClassArray(1) = new Class2
ClassArray(1).Name
ClassArray(2).Name
If both has a variable called Name.
Ways of managing classes dynamically.
Sorry if this is too vague or not possible. I’d appreciate any help. Sorry for the inconvenience.
Have you dimmed ClassArray to hold 3 elements?
Dim ClassArray(2) As ObjectOr else use Append():
Dim ClassArray() As Object
ClassArray.Append(New Class1)
ClassArray.Append(New Class2)
Thanks, I was confused cause object was not on the autocomplete.
Another question is getting another thing to work.
I have 2 classes, both with variables named “Name”. They’re both in the array yet ClassArray(1).Name doesn’t exist. Even if it is changed for class 2.
When you define an array as as array of class Object, the compiler doesnt know how to deal with expressions such as ClassArray(1).Name Object has no Name property. The individual instance accessed at runtime might be an instance of a subclass of Object that does have a Name property, but at compile time that is neither here nor there. However, you could first define a class NamedClass with a property Name of type String, define Class1 and Class2 (etc.) as subclasses of NamedClass, and declare ClassArray as Dim ClassArray() As NamedClass.
In addition to Michael’s advice, you can cast an object to another class as long as such a cast is legal.
For example, MySubClass is a subclass of MySuperClass. MySubClass has a property, “Name”, that does not exist in MySuperClass:
dim arr( 1 ) as MySuperClass
arr( 0 ) = new MySubClass // MySubClass is a MySuperClass, so this is legal
arr( 1 ) = new MySuperClass
s = arr( 0 ).Name // This will fail because MySuperClass doesn't define Name
s = MySubClass( arr( 0 ) ).Name // Casting it like this works
s = MySubClass( arr( 1 ) ).Name // This will fail at runtime as illegal castYou can also use a class interface.
say you’ve defined an interface “myInterface” with a “name” method. class1 and class2 both implement it.
then
Dim arr(2) as myInterface
arr(0)=new class1
arr(1)=new class2
s=arr(0).name
s=arr(1).name
This way the classes don’t have to be subclasses. They could be completely unrelated aside from the interface…
But note a class interface only works for methods, not properties. Of course one could implement Name as a method, but this would only complicate things.
True, I guess it depends if class1 and class2 are related and can be subclassed from the same class or each other. If you need to handle unrelated classes, the extra complication may be worth it. I would probably use a unique identifier if using an interface… the class may have a name property or not. You could have a displayName method in the interface that returns the appropriate value for that class, and a method that sets a value as and if appropriate/capable.
Properties are an implementation detail
Use a get / set pair of methods if you want a “property” like behaviour on an interface
That way the implementor can decide if it should be a property, something computed,etc.
Interfaces define a BEHAVIOUR contract - not an implementation contract.
[quote=57228:@Norman Palardy]Properties are an implementation detail
Use a get / set pair of methods if you want a “property” like behaviour on an interface
That way the implementor can decide if it should be a property, something computed,etc.
Interfaces define a BEHAVIOUR contract - not an implementation contract.[/quote]
But it would be nice if Xojo automatically behind teh scenes too care providing glue good for mapping properties to interfaces analogous to having different names for interface methods in the class so we don’t have to clutter the navigator with getter and setter methods that ONLY assign and get properties to satisfy an interface,
[quote=57228:@Norman Palardy]That way the implementor can decide if it should be a property, something computed,etc.
Interfaces define a BEHAVIOUR contract - not an implementation contract.[/quote]
I guess I’m reading this wrong. It sounds like you’re saying that, as long as you have Interface methods defined as setter/getter, you can implement that as a property in the class since the behavior of the property matches that expected by the Interface, but I just tried it, and that’s not the case.
Can you clarify what you mean by this?
You are reading it wrong…
Right now you have to have setter and getter methods that just get and set a backing property and map those methods to to the interface methods with the same signatures.
Lots of busy work to support “properties” in interfaces … Hence my post.
Your post agrees with my understanding of Interfaces, but Norman still seems to be saying something different, hence my request for clarification.
Some languages DO let you specify properties in an interface - but they behave more like method pairs in Xojo.
C# is a good example - but they are still method pairs under the hood.
In Xojo properties NOT being virtual is important.
The big reason properties are not virtual & cannot be overridden.
And thats important if you have an interface & a parent class implements the interface.
All subclasses will also implement the interface since they inherit the implementation.
And they CAN override methods - but they can’t do so for properties & this is a big deal in Xojo and for your code IF you set it up this way.
I’m pretty certain that using an actual property would force it to HAVE to be in the SAME location in the runtime memory model of ANY class that implements that interface - and THAT is a HUGE deal.
And gawd forbid you have two interfaces that require their properties be in the same location - your screwed.
Basically - aint gonna happen any time soon and not just to be ornery about it.
Technically it’s not just “let us put properties in there” - theres real issues doing this.
And properties are about HOW to do something not behaviour - interfaces are and should be about behaviour without dictating the HOW part of it.
[quote=57241:@Karen Atkocius]But it would be nice if Xojo automatically behind teh scenes too care providing glue good for mapping properties to interfaces analogous to having different names for interface methods in the class so we don’t have to clutter the navigator with getter and setter methods that ONLY assign and get properties to satisfy an interface,
[/quote]
Apparently in Mavericks the OS likes to autocorrect my typos, but guesses wrong most of the time…
Do just to be clear, that should have read:
But it would be nice if Xojo auto-magically behind the scenes took care of providing glue code for mapping properties to interfaces analogous to having different names for interface methods in the class, so we don’t have to clutter the navigator with getter and setter methods that ONLY assign and get properties to satisfy an interface,
What I was suggesting is that getters and settees for the property be generated invisibly behind the curtain to satisfy the interface getter and setter.
We would just specify what property to map the getter and setter methods. Basically take the drudgery out of it by doing what we would have to to do teh same thing … just hidden and automatically… Not sure why that would dictate where anything would have to be in memory…
[quote=57249:@Karen Atkocius]
What I was suggesting is that getters and settees for the property be generated invisibly behind the curtain to satisfy the interface getter and setter.
We would just specify what property to map the getter and setter methods. Basically take the drudgery out of it by doing what we would have to to do teh same thing … just hidden and automatically… Not sure why that would dictate where anything would have to be in memory…[/quote]
There’s no “curtain”
They need to be methods so, from a language & compilation point of view, things will work as expected when you have a super class implement an interface & a subclass then can override the parents implementation of an interface method.
Now IF we had syntax like C# does for implementing “properties” (which actually ARE GET / SET method pairs - maybe
But we don’t - so interfaces can’t have properties
I’m sorry but I do no understand your advice. I am trying to learn this language but it’s not easy. I have no idea what you are talking about. I guess I will show you my code example and you can maybe help by adding on to that and explaining as you go.
[code] dim ObjectArray() as Object
dim i as int32
dim test as object
ObjectArray.Append(New Class1)
ObjectArray.Append(new Class2)
while i=< ObjectArray.length then
if ObjectArray(i).Name=“Class2” then
end if
wend[/code]
I did not understand any of it so please. Treat me as a idiot.
The problem in the code is that Object has NO properties
So when you do
dim ObjectArray() as Object
dim i as int32
dim test as object
ObjectArray.Append(New Class1)
ObjectArray.Append(new Class2)
everything will be treated as if it is an “Object” instance - which means it has no name property.
SO when you get to the loop
[code] while i=< ObjectArray.length then
if ObjectArray(i).Name=“Class2” then
end if
wend[/code]
The compiler goes “This can’t work Object has no Name property”
What was suggested is that for classes you want to treat as being “the same” in certain ways was to define an interface and have your two classes implement that interface.
An interface is a way to have a class say “Hey I’m also one of these and if you treat me like one of these then I have these methods you can call”
So in your case maybe we define an interface called “NamedObject” that has one method “Name” that returns a string
Then you have Class1 implement this interface (which adds one method to it) and have Class2 implement the interface
Then you can do
dim ObjectArray() as NamedObject // <<<< note this will say treat everything in here as one of these
dim i as int32
dim test as object
ObjectArray.Append(New Class1)
ObjectArray.Append(new Class2)
while i=< ObjectArray.length then
if ObjectArray(i).Name="Class2" then // <<< and this WILL compile because any thing that is a NamedObject has a Name method
end if
wendI’d suggest you read the sections on interfaces in User Guide - Fundamentals Chapter 5
Have mercy with a beginner I still think that defining a common superclass with a Name property inherited by his various classes is both simpler to understand and simpler to implement. He can get the hang of class interfaces later, whereas at this stage this can get quite overwhelming and isnt strictly necessary to solve the issue at hand.
Common supers is certainly one way
Class interfaces are another