Is this expected behavior?
[code]dim btext as Boolean, bstring as Boolean
dim t as text
dim s as String
t = “1”
s = “1”
btext = IsNumeric(t) '<-- false
bstring = IsNumeric(s) '<-- true[/code]
I don’t know, but I would say yes. That’s how I would handle it:
[code]Dim t As Text = “1”
Try
Dim i As Integer = Integer.FromText(t)
// t is an Integer
Catch err as xojo.Core.BadDataException
// t is not an Integer
End[/code]
Since Text to string is implicit, the code should probably return true. The LR clearly mentions “A common usage of IsNumeric is to determine whether a user entered a string that can be converted to a number.”
In practice, A simple workaround is to affect the Text to a string before evaluation :
[code]Sub Action()
dim btext as Boolean, bstring as Boolean
dim t as text
dim s as String
t = “1”
dim tt as string = t
s = “1”
btext = IsNumeric(tt) '<-- false
bstring = IsNumeric(s) '<-- true
break
End Sub[/code]
You could also create a method such as TextIsNumeric(Text) as Boolean which does the same on a more generic level.
I don’t think so, because it would defeat the type safety of the new Text data type. Only Text to a declared String variable is implicit.
Given the extremely poor documentation of Text in the context of Desktop, where is it said it must be a declared variable ? And since the new LR does not even know about String, I would love to know where it could documented. Heck, we barely know about Text to String implicit conversion from Joe’s posts. And I don’t recall any such limitations from what he told us.
This method explicitly expects a string, yet it gracefully accepts Text as input, thanks to implicit conversion :
Sub msg(s as string)
msgbox s
End Sub
dim t as text = "Hello there"
msg t
IsNumeric expects a variant, so the process of determining the variant type to proceed, is probably not implemented yet into isNumeric. Vartype for Text is 37, which does not appear yet in the LR. I bet a select case is missing within the method that would correctly return True.
The method does accept Text as input, but the result is wrong. The result is the bug.
Maybe a gentle Xojo engineer can enlighten us ?
[quote=165754:@Michel Bujardet]This method explicitly expects a string, yet it gracefully accepts Text as input, thanks to implicit conversion :
Sub msg(s as string)
msgbox s
End Sub[/quote]
Exactly my explanation: if you have a String declared - here called s -, then Text will silently convert.
I think one should not mix the old and the new framework, especially not Text and Variant. Variant is not deprecated, but it should be IMHO.
I made feedback case 38097 for this. You can join.
[quote=165797:@Eli Ott]Exactly my explanation: if you have a String declared - here called s -, then Text will silently convert.
I think one should not mix the old and the new framework, especially not Text and Variant. Variant is not deprecated, but it should be IMHO.[/quote]
Eli, you are getting a bit extreme 
Text and Auto maybe better, yet String and Variant have valorously serve the community since the onset of RB. And since we have been assured they will remain for a long time, why call for their deprecation prematurely ?
On a personal level, you may perfectly well decide to do away with older types, and it could make sense since they simply do not exists in iOS. But I just imagine the disarray of so many, if suddenly Variant was not available anymore.
Thank you.
deprecated <> not available anymore
I am Michel, I am…
Let me clarify a few points.
Formally deprecating a feature is not the same as removing it. It is just the beginning of the removal process and deprecated features don’t always have a fixed deadline for removal. The general idea is that this will eventually be removed, new code should use replacement APIs, and old code should be migrated to them over time. Formal deprecation also means that the compiler will issue a deprecation warning when you use the deprecated functionality.
To give a few examples:
- The language’s Inline68k keyword has been deprecated since 2003, but was retained to keep very old code that we knew was in fairly widespread use to keep compiling (the Carbon Declare Library). Since the Carbon framework no longer exists, this compatibility issue is irrelevant and Inline68k will be removed later this year.
- FolderItem.AbsolutePath is deprecated because it’s something we want to push people away from using because HFS paths no longer make sense. There are no plans at this point to remove it.
Any feature removed from the language or framework goes through this process, unless the ‘feature’ is actually a bug that incorrect code relied on. Unfortunately there are some cases where this simply isn’t possible, like the removal of QuickTime support. In that specific case we weren’t given much of an option given the Mac App Store restrictions.
Getting back to the discussion of String and Variant, neither have been formally deprecated yet. This isn’t going to happen for a few years and their removal is even farther out, if it ever happens.
@Joe:
Casting and implicit conversion often cause problems.
Would it be possible to do away with implicit conversion and casting and replace it with something consistent? What I mean is:
Variant has “extensions” like .integer or .string
Could it be automatically extended to account for any class in a project?
So that aString = aVariant is a syntax error. It has to be aString = aVariant.StringValue
Or for classes: aClassInstance = aVariant.aClass instead of aClass( aClassInstance ) = aVariant
Seems nicely readable and consistent.
I agree. This is why the Auto data type preserves its original type information and raises an exception if you assign it to something of a different type. Variant, on the other hand, would contort its data as much as possible to make the assignment succeed (for example, converting a color to an integer).
[quote=165859:@Markus Winter]Would it be possible to do away with implicit conversion and casting and replace it with something consistent? What I mean is:
Variant has “extensions” like .integer or .string
Could it be automatically extended to account for any class in a project?[/quote]
No, this would break a huge amount of code for relatively little gain.
You could make it a warning, that way it would not break code. Plus maybe a note that in the future this would be the way to go.
The extension of variant however should not break any code and would immediately improve readability and consistency.
It would if you already had members with the same name as data types. It also has the problem of not being able to handle namespaces correctly.
Is that likely? Surely I can’t declare a class or property “string as myClass” anyway?
One more reason why I dislike namespaces. Much better (and good for readability and autocomplete) to have a suffix like
Timer
TimerMBS
TimerBK
TimerMW
than
Xojo.Core.Timer
MBS.Controls.Timer
BK.BetterControls.Timer
MW.Timer
You can, but I certainly don’t recommend it.
Uhh, have to try then [evil grin]
I disagree about the suffix. Namespaces are life savers if you ask me (which you didn’t).
Example: BKS Shorts has document, page, text, oval, rectangle, etc. classes. BKS_Shorts.Page means way more than PageBKS. What do I do if I have another Page class with the PDF classes? PagePDFBKS? Much better to say BKS_PDF.Page so there’s absolutely no confusion with BKS_Shorts.Page.
Almost all of our recent stuff is using Namespaces because it eliminates ANY compiler confusions. We like it much better than trying to use a suffix. And now that autocomplete works with Namespaces (it didn’t for years) it’s way more consistent and useful.
So with the namespace I will NEVER have to worry about a conflict with someone else who has a page, document, text, oval, rectangle, etc. class. With a suffix I have to go through gyrations to make sure multiple products that do similar things (i.e. Shorts and PDF) don’t conflict.
Your comments are ALWAYS appreciated, wether you agree with me or not 