Yeap Kem and that is why I wrote above things since I think it’s better to have something which become defacto standard in our world to be implement by maker of Xojo rather then to play and work around for it which will not be a same.
This would make Xojo more better and powerfully if they integrate with framework.
@Geoff Perlman
I did and provide my sample along with it and no reply till now
Feedback #50073 (on this no reply at all)
Feedback #49909 (this ended by putting status - Closed - By Design)
Now that was good programming practice on the old framework anyway. Information btw that I miss in the documentation, especially as good programming practices are ignored for most bare bone examples, leading newbies to write poor code by example. So a chapter “Good programming Practices” seems like a good idea.
The problems is there its a LOT of that type of stuff in the new framework compared to the old and it makes it feel like your are slogging through mud rather than being able to express your design…
There needs to be a balance between safety, convenience and accessibility… I think the old framework comes closer to the right balance of those things than the new, for people like me
Would it be possible to have String Auto Convert to Text with an automatic encoding of UTF8 if there is no encoding on the string? Maybe as a Project Setting?
Autoconversion like this could throw exceptions
You can’t always convert from String with a nil encoding to text as UTF-8 encoded (or any encoding for that matter)
Nil encoded strings aren’t necessarily “text” data
For MBS Plugins in a lot of places, I check if nil encoding of a string still contains valid UTF-8 data and than use it as UTF-8.
If it’s not valid UTF-8, we use it like ISO Latin or MacRoman as fallback.
Works fine for most users and keeps support cases low.
At least much lower to the time where I did throw exceptions for having no encoding.
Throwing an exception would be acceptable. There are a lot of cases where not having a string with a defined UTF8 encoding is, well, exceptional. Having an autoconversion from string to text would really ease the pain of transitioning to the new framework.
FWIW, I do use a mixture of old and new frameworks in several of my projects. The largest pain point I’ve run into is the difficulty getting Strings to Text, and the inherent confusion when some things have a .text property that is actually a String.
It’s not a “pulling my hair out and cussing at Norman” sort of issue, but it does slow me down from time to time. I agree with @Tim Hare and others who have expressed a similar sentiment in this thread: an automatic conversion that handled 90% of the cases from String to Text would be helpful.
So you understand the implications of such a design because it does have implications not just today but potentially for a long time
And it may in fact make your applications larger than they need to be
.ToText already does most of what is being asked for - its not automatic though
And it has the added benefit that when the new framework can replace the classic one we aren’t still having to build in the old framework because of all these autoconversion dependencies
Right now ToText on String is essentially
ToText(extends S as string) as Text
And if you NEVER use this in your code then it wont cause string to be included (there may be other reasons but not this one)
Its at least one dependency that doesn’t make it so we have to build String and the classic framework in all the time
But if we have something like
Text = String
and it’s roughly implemented as
Text(assigns S as string)
then the TEXT item depends on string being there - always
and the only way to NOT have this is to remove this
So we would HAVE to build in the new framework & old one until we removed this dependency
And if at some future date we do remove this and you haven’t updated your code then we suddenly break your code because we removed this one item
We don’t like to break your code or projects
We’re trying to move the frameworks & Xojo forward AND preserve your investment of time and effort
Thanks for the explanation, Norman. A few thoughts:
I don’t care at all about built application size. The size of my artwork FAR exceeds the dependencies size for the delivered application. Other users I’m sure do care, but in today’s world of all-digital delivery and fast connections for my end users, downloading something that is an extra 20MB is not something that makes a lick of difference to me in the slightest.
As you’ve pointed out, as soon as my app has a String in it at all (or, indeed uses ANY items in the old framework), you have to build both frameworks. I cannot move away from items in the old framework until the new framework is feature-rich enough to completely replace everything I’m currently doing in the old framework. That appears to be multiple years into the future, so for now there is no way to avoid compiling both frameworks, regardless of the inherent dependencies that may or may not exist between the 2.
Now I certainly understand the need to avoid perpetuating a long-term dependency between the frameworks (as in your Text(assigns S as String) example above) but for the forseeable future, adding such a convenience method would save a LOT of headache for those of us currently using parts of both frameworks right now. Deprecate it in the future (with compiler warnings) once more of the new framework has been ironed out, and allow several releases to have folks have the opportunity to remove any dependencies on the old framework.
But seriously, we’re talking about stuff that is multiple years down the road, and while I appreciate the need to be forward thinking in your design, it’s obvious that the community feels that the new framework just has too many rough edges to be embraced as the new one true way. Please consider ways to make it easier to embrace in the short term, but make it possible to undo the dependencies you mention in the far long term.
Building all these dependencies into the new framework would more practically mean we could NEVER remove the classic framework regardless of how functional the new framework is
So we need to actively avoid painting ourselves into a corner now where we can NEVER remove the classic framework
(It has taken nearly 20 years to get to the point where a new framework was even started despite a really pressing need)
Hence - there’s no autoconversion from String to Text as it is one of those corner painting items
We also cant support some of these because there is NO classic framework on iOS
We’d have to write one (there is no port possible as the classic framework depends on many deprecated items that have no counterpart in the OS API’s)
So dependencies in the new framework have to be severely limited
So we can certainly add “Convert To” type extensions (ie/ String.ToText) to the classic framework since they wont affect iOS at all
Just not “convert from” - like autoconversions - as they cant be supported on iOS
And I suspect that this would be true for new targets like Android as well
It seems obvious to me that auto conversion of String To text should have been in place from the first day the new framework was available on the desktop to help make the transition easier for us… but I have to say it really seems as though ideological purity was a higher concern than making the transition as easy as possible for us… and that bothers me…
They HAD to know upfront that we would be dealing with a mixed framework for a good number of years, so the concern with App size for the LONG interim was obviously misplaced. It’s been 3 years and it will be several years more before using the the new framework alone apps on the desktop will be reasonable…
I understand wanting to do something “once” and do it “right”… but Beta was “better” than VHS…
RB/RS did as well as did primarily because of ease of use as well as being XPlatform… That was the bedrock it seemed to be built on.
Autoconversion of String to Text is not there for the reasons I listed above
It WOULD tie our hands long term
Thats why we added ToText since it autocompletes which makes it reasonably convenient and the makes your intent clear since its explicit
We’re trying to think not of the next 3 -5 years but the next decade or more and trying to avoid some of the pitfalls that exist in the classic framework that repeatedly bite everyone
If the classic framework is not going away for 5, 10, or more years does that mean that only iOS and new targets will be 100% new framework and Desktop and Web will be mixed frameworks long term?
It’s not just you. “String” is ubiquitous in every programming language I have ever used. Replacing it with “Text” makes Xojo just a little more oddball for people exploring it who already have a deep background in lots of other languages.
