Question about object oriented dot notation style in FB

[kcvinu]

Hi all,
In Visual Basic.Net, A combobox class has an Items property. And it is an indexed property. We can get the items by passing an index as parameter. On the same time, this Items property has some fields and methods like "Add", "Count", "Clear" etc.
My question is, how to do it in FreeBasic ?. I have a combobox type and it contains an Items type. So members like Add, Clear are working very well. I can use the dot notation like this --> "ComboBox.Items.Add("Item1").
But when it comes to an indexed property, compiler gives error messages . And here is the model i am working now. It is not the actual code. But if this prototype worked, i can adapt this into my code.

Code: Select all

Type ItemsClass Extends Object
	sList(Any) As String	
	 
	Declare Property Count() As Integer
	Declare Sub Add(Byval Item As String)
	Declare Sub Clear()
	Declare Sub RemoveAt(Byval Index As Integer)
	Declare Sub Insert(Byval Item As String, Byval Index As Integer)
	
End Type

Property ItemsClass.Count() As Integer
	Return Ubound(sList)
End Property
Sub ItemsClass.Add(Byval Item As String)
	ArrayAdd(sList, Item)	' ArrayAdd is a simple macro. It just redim and put things into array.
End Sub
Sub ItemsClass.Clear()
	Erase sList
End Sub

Type ComboBox
	 
	Items As ItemsClass
	Declare Property Items(Byval Index As Integer) As String	
End Type

Property ComboBox.Items(Byval Index As Integer) As String
	Return This.Items.sList(sInd)
End Property

Dim cmb As ComboBox
cmb.Items.Add("Sample val1")
cmb.Items.Add("Second Val")
Print cmb.Items(1)

Sleep
End

About the error messages -
1. Property declaration of Items in Combobox - Duplication definition. - (Do i need an Overload clause ?)
I think i am confusing compiler with giving same names for a property and a member type.

[fxm]

I think i am confusing compiler with giving same names for a property and a member type.

Yes.

[kcvinu]

@fxm,

Yes.

Then, how do i tell compiler to treat this property as a different entity and member as a different entity ?
Edit -- Without renaming. Because, i need the same name.

[Tourist Trap]

Edit -- Without renaming. Because, i need the same name.

I m just jumping into it "en passant".It reminds me this information from fxm given monthes ago after I had some issue similar at first sight:
viewtopic.php?p=214111#p214111

[fxm]

A little twisted:

Code: Select all

Type ItemsClass Extends Object
   sList(Any) As String
   
   Declare Property Count() As Integer
   Declare Sub Add(Byval Item As String)
   Declare Sub Clear()
   Declare Sub RemoveAt(Byval Index As Integer)
   Declare Sub Insert(Byval Item As String, Byval Index As Integer)
   
End Type

Property ItemsClass.Count() As Integer
   Return Ubound(sList)
End Property
Sub ItemsClass.Add(Byval Item As String)
   ArrayAdd(sList, Item)   ' ArrayAdd is a simple macro. It just redim and put things into array.
End Sub
Sub ItemsClass.Clear()
   Erase sList
End Sub

Type ComboBox
   
   Declare Property Items() Byref As ItemsClass
   Declare Property Items(Byval Index As Integer) As String  
   Private:
      _Items As ItemsClass
End Type

Property ComboBox.Items() Byref As ItemsClass
   Return This._Items
End Property

Property ComboBox.Items(Byval Index As Integer) As String
   Return This._Items.sList(Index)
End Property

Dim cmb As ComboBox
(cmb.Items).Add("Sample val1")  '' but parentheses here are mandatory
(cmb.Items).Add("Second Val")   '' but parentheses here are mandatory
Print cmb.Items(1)

Sleep
End

[edit]
- Error correction on Items properties.

[paul doe]

I think i am confusing compiler with giving same names for a property and a member type.

Confusing the compiler should be the least of your concerns. It is YOU, the one who read the code, that has to be able to tell, at a glance, what the code is doing, or which member/variable/whatever you're referencing. Appropriate naming conventions and good object design are paramount to this. This code works as intended, but I wouldn't enforce it:

Code: Select all

type CItem extends object
	public:
		declare constructor()
		declare constructor( byval value as integer )
		declare property item() as integer
		
	private:
		m_item as integer
end type

constructor CItem()
	m_item = 0
end constructor

constructor CItem( byval value as integer )
	m_item = value
end constructor

property CItem.item() as integer
	return( m_item )
end property

type Items extends object
	public:
		declare constructor()
		declare function item( byval as integer ) as CItem
		declare property count() as integer
		declare sub add( byval as integer )
		
	private:
		m_items( any ) as CItem
		m_count as integer
end type

constructor Items()
	m_count = 0
	redim m_items( 0 to m_count - 1 )
end constructor

property Items.count() as integer
	return( m_count )
end property

sub Items.add( byval nItem as integer )
	m_count += 1
	redim preserve m_items( 0 to m_count - 1 )
	
	m_items( m_count - 1 ) = CItem( nItem )
end sub

function Items.item( byval index as integer ) as CItem
	return m_items( index )
end function

dim il as Items

for i as integer = 0 to 9
	il.add( i )
next

for i as integer = 0 to il.count - 1
	? il.item( i ).item
next

sleep()

By the way, it is about time that FreeBasic adds support for default properties, since the above code looks very stupid and redundant.

[kcvinu]

@Tourist Trap,
Thanks for pointing me to that article. Let me read it.

@fxm,
Could you please tell me why those parenthesis were mandatory ? . I wish, to find a way to get rid of from those brackets.

[Tourist Trap]

By the way, it is about time that FreeBasic adds support for default properties, since the above code looks very stupid and redundant.

Hi paul doe,

I remember approximately that dkl answered me about this suggestion. Rather than allowing adhoc default properties, he was more inclined to allow the operator parenthesis to be overloaded. Not remembering any detail (I hope he didn't mean the exact contrary ahah!), but I think it would be rather powerful this way and content everyone.

[paul doe]

...
Rather than allowing adhoc default properties, he was more inclined to allow the operator parenthesis to be overloaded. Not remembering any detail (I hope he didn't mean the exact contrary ahah!), but I think it would be rather powerful this way and content everyone.

Yeah, that seems like a neat idea. However, doing that could mean that you can overload the parens with any datatype, which kind of defeats the purpose of a default property. But could be pretty cool, nonetheless =D

[paul doe]

Could you please tell me why those parenthesis were mandatory ? . I wish, to find a way to get rid of from those brackets.

Mmm, seems like they're mandatory even with byref functions:

Code: Select all

type CItem extends object
	public:
		declare constructor()
		declare constructor( byval value as integer )
		declare property item() as integer
		
	private:
		m_item as integer
end type

constructor CItem()
	m_item = 0
end constructor

constructor CItem( byval value as integer )
	m_item = value
end constructor

property CItem.item() as integer
	return( m_item )
end property

type CItems extends object
	public:
		declare constructor()
		declare function item( byval as integer ) as CItem
		declare property count() as integer
		declare sub add( byval as integer )
		
	private:
		m_items( any ) as CItem
		m_count as integer
end type

constructor CItems()
	m_count = 0
	redim m_items( 0 to m_count - 1 )
end constructor

property CItems.count() as integer
	return( m_count )
end property

sub CItems.add( byval nItem as integer )
	m_count += 1
	redim preserve m_items( 0 to m_count - 1 )
	
	m_items( m_count - 1 ) = CItem( nItem )
end sub

function CItems.item( byval index as integer ) as CItem
	return m_items( index )
end function

type ComboBox 
	public:
		declare function items() byref as CItems
		declare function items( byval as integer ) as integer
		
	private:
		m_items as CItems
end type

function ComboBox.items() byref as CItems
	return( m_items )
end function

function ComboBox.items( byval which as integer ) as integer
	return( m_items.item( which ).item )
end function

dim cb as ComboBox

for i as integer = 0 to 9
	(cb.items).add( i )
next

for i as integer = 0 to cb.items.count - 1
	? cb.items( i )
next

sleep()

[kcvinu]

For the time being, I am satisfying with a name change like this. A Little compromise .

Code: Select all

Type ItemsClass Extends Object
	sList(Any) As String	
	 
	Declare Property Count() As Integer
	Declare Sub Add(Byval Item As String)
	Declare Sub Clear()
	Declare Sub RemoveAt(Byval Index As Integer)
	Declare Sub Insert(Byval Item As String, Byval Index As Integer)	
End Type

Property ItemsClass.Count() As Integer
	Return Ubound(sList)
End Property
Sub ItemsClass.Add(Byval Item As String)
	ArrayAdd(sList, Item)
End Sub
Sub ItemsClass.Clear()
	Erase sList
End Sub

Type ComboBox 	
	Items As ItemsClass
	Declare Property GetItems(Byval Index As Integer) As String 	  
End Type

Property ComboBox.GetItems(Byval Index As Integer) As String
   Return This.Items.sList(Index)
End Property

Dim cmb As ComboBox
cmb.Items.Add("Sample val1")   
cmb.Items.Add("Second Val")    
Print cmb.GetItems(1) 

Sleep
End

[fxm]

I wish, to find a way to get rid of from those brackets.

Do not ask me for the moon!

[Tourist Trap]

@fxm,
Could you please tell me why those parenthesis were mandatory ? . I wish, to find a way to get rid of from those brackets.

I can't tell you the tech inside. But I can give you the way I remember this rule. Always say to yourself this: the parenthesis can resolve the ambiguous things because they force evaluate the expression in a way or an other.

Here if you put the parenthesis, if the fbc doesn't want to trigger an error, what is inside the parenthesis can not be a value, it has to be a procedure of some kind. (THIS.Items)(...) is then the property.

edit: if Items was also an array, I don't know what would happen. Double parents required?

Code: Select all

 type Y
	as integer Moon(1)
end type

type X extends Y
	declare property Moon(as integer)
	declare property Moon(Index as integer) as integer
	
End Type
property X.Moon(GetValue as integer)
	BASE.Moon(1) = GetValue
end property
property X.Moon(Index as integer) as integer
	return BASE.Moon(1)
end property


dim as X  xxx

? xxx.Moon(0)	'crash win10 64
? (xxx.Moon)(0)	'error 193: PROPERTY has no GET method/accessor


sleep

[paul doe]

For the time being, I am satisfying with a name change like this. A Little compromise .

Why are you bothering? In the code you posted, the Items member of the combobox 'class' is public, so you don't need an accessor to reference it:

Code: Select all

Type ItemsClass Extends Object
   sList(Any) As String   
   
   Declare Property Count() As Integer
   Declare Sub Add(Byval Item As String)
   Declare Sub Clear()
   Declare Sub RemoveAt(Byval Index As Integer)
   Declare Sub Insert(Byval Item As String, Byval Index As Integer)   
End Type

Property ItemsClass.Count() As Integer
   Return Ubound(sList)
End Property
Sub ItemsClass.Add(Byval Item As String)
   ArrayAdd(sList, Item)
End Sub
Sub ItemsClass.Clear()
   Erase sList
End Sub

Type ComboBox    
   Items As ItemsClass
End Type

Dim cmb As ComboBox
cmb.Items.Add("Sample val1")   
cmb.Items.Add("Second Val")   
Print cmb.GetItems(1)

Sleep
End

That is, of course, if the code you're posting isn't the complete code...

[kcvinu]

Do not ask me for the moon!

@fxm,
Ha ha ha.. Never..