-
Feb 16th, 2017, 02:56 PM
#1
Thread Starter
Lively Member
Nested classes (or how to “group” properties)
Hi !
I would like to build a nested class hierarchy. Something that would help to categorize, let's say group objects (mostly properties) by genre while using Intellisense.
i.e. From :
Code:
Class MyHouse
[+] Property Tv
[+] Property Kitchen
[+] Property Radio
[+] Property Bathroom
[+] Property Computer
[+] Property Crib
[-] Property Bedroom
Get...
Set...
End Property
End class
To :
Code:
Class MyHouse
|
|-----Class Rooms
| [+] Property Bathroom
| [+] Property Bedroom
| [+] Property Kitchen
| ...
|
|-----Class Objects
| [+] Property Radio
| [+] Property Tv
| [+] Property Computer
| [+] Property Crib
| ...
|
End class
The main objective is to have intellisense using the hierarchy.
So I nested a class within another, and shared it's members :
Code:
Friend class MyHouse
|
| Friend class Rooms
| |
| | Private shared kitchen_ as clsRoom
| | Friend shared Property prop_kitchen
| | Get
| | Set
| | End Property
| | ...
| |
| End class
| ...
|
End Class
The problem is when I create a new object and want to access it's nested properties, I get the following error :
access of shared member through an instance, qualifying expression will not be evaluated
But I don't want to instantiate the sub classes.
I'm just looking for a good way to have a hierarchy to "organize" the whole class, and directly access it's members.
About the same way we do when we browse the .NET framework.
Any way doing this without having to deal with classes instances?
Thanks in advance
Last edited by castaway; Feb 16th, 2017 at 03:01 PM.
-
Feb 16th, 2017, 03:53 PM
#2
Re: Nested classes (or how to “group” properties)
Classes are like recipes in a cookbook. They describe how to make objects. You have to create an instance of a class to use it for the same reasons eating a cookbook isn't the same thing as eating a cookie.
The "Shared" keyword doesn't mean sharing in the same sense as what you think.
Normally, a variable belongs to the specific instance of the class that contains it. This is like saying, "Every individual cookie has its own chocolate chips." If I ask, "How many chocolate chips?" you can't answer the question until I also answer, "On which cookie?"
When a member is "Shared", it belongs to the class, not instances, and every instance "shares" the same copy of that property. This is like the author of the recipe. If I hold up a cookie and say, "Who wrote this recipe?" it doesn't matter WHICH cookie I'm holding. You get that information from the recipe, and the answer's the same for every cookie made from that recipe.
In terms of your code, that means you can't get what you want without creating instances of the types. It's very hard for me to describe what I think you have and exactly how it doesn't deliver what you want, so I'd rather leave it at that.
-
Feb 16th, 2017, 09:11 PM
#3
Thread Starter
Lively Member
Re: Nested classes (or how to “group” properties)
Hi Sitten Spynne,
When a member is "Shared", it belongs to the class, not instances, and every instance "shares" the same copy of that property
Thank you very much for the clear explanation with cookbook. It helped me a lot.
For classes that need a lot of different instances (like a lot of cookies!) it makes total sense.
-------------------------
What still confuses me here, however, is the fact that my parent class is already being instantiated, so already has it's own "copy", right ?
Because I don't need different instances of the nested data. Just one.
So this is fine : Usual structure where we have Class.Properties
Code:
Friend class MyHouse
|
| Private bolKitchen as boolean
| Friend Property prop_HasKitchen as boolean
| Get
| Set
| End Property
| ...
|
End Class
And I just need to have : Class.Category.Properties
Code:
Friend class MyHouse
|
| Friend class Rooms
| |
| | Private shared bolKitchen as boolean
| | Friend shared Property prop_HasKitchen as boolean
| | Get
| | Set
| | End Property
| | ...
| |
| End class
| ...
|
End Class
So by shared, I actually meant to have access to the same copy within the Parent class instance MyHouse.
Maybe that's why it's not really an error, rather a warning that I get. Maybe it does actually work the way I intended ??
-------------------------
Anyway, if it's not a proper way of coding, I will change.
This is what I came up with. I splitted both classes and simply did :
Code:
Friend class MyHouse
|
| Friend Rooms as new cls_Rooms
|
| ...
|
End Class
I can now access to a class.category.properties kind of style of hyerarchy
Code:
MyHouse_.Rooms.<properties>
It just doesn't show the way I wanted (I would have preferred in intellisense do distinguish better, like with a class icon, not a usual field|property icon, but this really isn't a big deal !
Hope this is a better now... at least in my code I got no more warnings
Thanks a lot!
castaway
-
Feb 17th, 2017, 07:47 AM
#4
Re: Nested classes (or how to “group” properties)
I'm not sure where to begin... there's so much.... I don't want to say wrong... but inaccurate might be better ... in that last post that..... I just can't let it go.
It's showing up as a field icon because that's how you declared it... if you want it as a class icon, then you need to declare it as a PROPERTY.
Actually... you should be building the class as it should be on function, not form.
1) build the base class "ARoom"
Code:
Public Class ARoom
Public Property Width as decimal
Public Property Length as Decimal
Public Property Name as String
Public Property Description as String
Public Property VaultedCeiling as boolean
End Class
2) Now define the house, and with it, create rooms:
Code:
Public Class AHouse
Public Property Kitchen as new ARoom
Public Property LivingRoom as new ARoom
Public Property MediaRoom as new ARoom
Public Property Bedrooms as new List(of ARoom)
End Class
3) Now create the house...
Code:
Dim MyHouse as new AHouse
4) Now I can access the Kitchen, LivingRoom and MediaRoom ... the BedRooms will take a little more work, but know that you can create and access those as well:
Code:
MyHouse.Kitchen.Description = "Where the food gets cooked"
Not once did I use Share or Friend or anything else...
the Share keyword means just that ... it is SHARED across ALL instances... it doesn't belong to any one instance. So when you access a Shared somethign (property or method) you access it through the base class, NOT through an instance of that class. Because it doesn't belong to any instance.
If you want a property of HasKitchen....
Code:
Public Class AHouse
Public Property Kitchen as new ARoom
Public Property LivingRoom as new ARoom
Public Property MediaRoom as new ARoom
Public Property Bedrooms as new List(of ARoom)
Public ReadOnly Property HasKitchen
Get
Return Kitchen IsNot Nothing 'Returns True if Kitchen is not nothing, returns False if it is nothing
End Get
End Class
So now if MyHouse.Kitchen = Nothing happens... MyHouse.HasKitchen will return false.
-tg
-
Feb 17th, 2017, 10:02 AM
#5
Thread Starter
Lively Member
Re: Nested classes (or how to “group” properties)
Hi techgnome,
Thanks a lot for taking the time to answer.
My first try (building nested classes) was not the proper way to go indeed.
But then the second time, I believe I did exactly what you explained, at the end of my post. (don't mind the beginning, I was still 'searching').
So I built up a (usual) class for a Room, another (usual) class for a House, and just instantiated the child class (rooms etc..) in the main class (House).
Now I have the structure I wanted. It was that simple, no need to sub-class.
For the icon, as I said here, it's not a big deal I tryed the field -and- property type, and I can use it like this, no problem.
Just one think to correct however
(I would have preferred in intellisense do distinguish better, like with a class icon, not a usual field|property icon, but this really isn't a big deal !
It's showing up as a field icon because that's how you declared it... if you want it as a class icon, then you need to declare it as a PROPERTY.
Fields looks like a blue little box, and properties like a black little wrench, but not a class. At first I wanted a class to show there is more "sub-items" when using intellisense. On a small project it's irrelevant, but on a huge projects with dozen of classes and a full structure, this could really improves readability when using objects, making it more efficient.
But as I said, it's really no big deal, the code is now perfect, and not using shared or anything else
Thanks a lot !
Last edited by castaway; Feb 17th, 2017 at 10:10 AM.
-
Feb 17th, 2017, 11:08 AM
#6
Re: Nested classes (or how to “group” properties)
That's not going to work, as you've already figured out. What Intellisense is showing you has to be consistent across whatever items it has to show for whatever object you happen to be showing. So, it shows members for a class, and it gives those members different icons for their type. But what you are looking for would require Intellisense to show different icons for different return types, and THAT is a problem with no finite solution. Some members have return types (properties and functions), some do not (member variables and Subs). So, now you have to have a different icon for the different return types plus what kind of icon for those members that don't return anything? Is any answer to that fully consistent? I would argue that it isn't. Furthermore, return types can be all over the board. You seem to suggest that all return types that are classes can have the same icon, but that seems like a really poor choice. At the very least, if the icon were to be based on return type, then I'd want collections to have a different icon from a single class. Also, would an integer have a different icon than a List(of Integer), which happens to be a class...and a collection?
As you can see, there are any number of ways the icons in intellisense could have been set up. What they went for was a simple, consistent, schema where the different types of members had different icons, without regard to what they returned, or whether they returned anything at all. The alternative would be forever debatable.
My usual boring signature: Nothing
-
Feb 17th, 2017, 11:40 AM
#7
Thread Starter
Lively Member
Re: Nested classes (or how to “group” properties)
I don't know what I wrote wrong. Sorry if I mislead someone. I'm not looking to change icons or whatever...........
I said from the start I tryed to have nested elements, so that when browsing my object, I would have a hierarchy.
That's all !
Then yes I first went with the nested class idea, because ideally I would have liked intellisense to distinguish those objects (having nested elements) like classes in the hierarchy. But since the coding was wrong with the nested classes approach, I changed it (adding an instance of an external class) and it does the job better.
I just wanted to correct techgnome when he said "If you want it as a class icon, then you need to declare it as a PROPERTY", which actually, is not correct.. if I declare as a property, it shows with a property icon (black wrench), not a class. This was just a side-correction.
Again, adding an instance of a sub-class in my main class is all that was needed.
Thanks =)
Last edited by castaway; Feb 17th, 2017 at 11:46 AM.
-
Feb 17th, 2017, 11:47 AM
#8
Re: Nested classes (or how to “group” properties)
Yeah, we got off into the weeds.
You say what you want, we'll interpret it how we want....and then we'll run off like wild bulls.
My usual boring signature: Nothing
-
Feb 17th, 2017, 11:55 AM
#9
Thread Starter
Lively Member
Re: Nested classes (or how to “group” properties)
something like this
-
Jan 24th, 2021, 05:58 PM
#10
New Member
Re: Nested classes (or how to “group” properties)
Exactly the information I was looking for. Thank you!
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|