[quote=493148:@Rick Araujo]Not converting into another language, just fixing some idiosyncrasies of the language enabling a better, organized, free style coding. A pure, correct, text format Xojo will be per se a redesign of the language.
[/quote]
NOT. CONNECTED. AT. ALL.
A plain text format for I/O could be done without changing ANYTHING in the language
Or the language could be entirely revised and not touch the file formats
Do we have some kind of “Imports” in the language? Support for folder structures? Not saying those cryptic #tag whatever that MUST DIE, I mean pure language support.
None of those are part of the language currently and a plain text file format could be done for the language as it exists today
IMPORT would be a new addition
So I don’t know why the initial disagreement.
[quote=493132:@Rick Araujo]
But first the language must evolve a bit to support things like includes, local functions and local classes (functions inside functions, classes inside classes/functions) for example, things as we all write when doing it freely.[/quote]
Because … this ^^^^^^?
A plain text format is NOT required to support imports
A plain text format COULD exist and NOT support imports
IMPORT doesnt REQUIRE a plain text format like you seem to keep implying
Xojo could implement “Imports” in the IDE the way it is today - its just not terribly useful in the way C or C++ #include is
OR Xojo could devise another file format that is purely text and NOT have an ability to do “imports”
they do not depend on each other in any way
NOW… would a plain text format be nice - sure
Would it be nice to have “imports” - really depends on what it would be used for since Xojo doesnt need it like C does (so I’m not sur what it would DO)
Would a cmd line compiler be nice - sure
But nice ? required
1 Like
Sure it’s not required. We could even shrink language and make it a subset make things even easier using such arguments. But my thoughts were based on the current offers we already have from other similar languages, where newcomers using a text editor with project tree organized in folders visible by the side are used to. Also the internal way of reusing code, I remember hating to repeat a small piece of code inside a function 3 times because it made no sense to put such code outside the function floating around, 2 ugly options, and people will try local coding as in any language, including other Object Basic based ones, and become puzzled why it does not work, as for a source tree, separating code of libs and concerns, physically, in different folders, it’s also the usual way the devs are used to handle the organization. Can we do it in pile of mess in a huge source? Sure. But as others don’t, why we should? This is a kind of “nice” that is required if we want to have something useful and attractive at the end, or people simple will not care, call it toy, and use something else.
I don’t know what you mean by this. Everything I edit in the IDE, I’m doing manually.
Manually writing it, not endless clicking to visually add items, edit the names and properties
You mean you’d like to type something like:
[quote]Object Window
name: mainWindow
top: 25
left: 33
height: 50
width:200
title: “My Window”
end object
object button
parent: mainWindow
name: myButton
top: 10
left: 25
height: 20
width:60
end object
eventHandler
object: myButton
event: action
parameters: None
Sub
// code goes here
End Sub
end eventHandler
[/quote]
and you want to let’s say do this in a text editor such as BBEdit and save it with the other project items so that the IDE picks it up?
Maybe this video will show the efficiency of adding properties in code. (Sorry my gif recorded left some ‘droppings’ toward the end of the clip)
Sure, thats the idea. Maybe windows and buttons are easier to edit on the designer, but Enumerations, constants and other ithems are a reall pain to edit, clicking the tiny plus button, two clicks to edit the name, really ackward. Editing the object containing the enum you could save a LOT of time. Same for constants and others.
Public enum Demo
demoval1
demoval2
demoval3
demoval4
End enum[quote=493237:@Ivan Tellez]Same for constants and others.
[/quote]
https://github.com/npalardy/Enum-Extender
well XOJO is very small company to compare with MS.
MS is Big $$$$$$.
Exactly the point. VS code is free to use and you can define a grammar file to supply the syntax highlighting and with a bit of work even implement the more advanced code checking and auto complete.
Let the big company, and the thousands of contributors, work to improve an alternate IDE. This gives Xojo more time to focus on the framework. I’m content to let the language be the way it is. Instead let’s see fixes for the bugs that have been hanging out there for years. Also I think being able to have more open source code files would drive adoption, 3rd party libraries and community tooling.
Also as Norman mentioned…Yes please allow external modules, with classes. This drives me nuts.
These sort of feasible, if not trivial changes, would really allow Xojo to be adopted by more professional users. Xojo is pretty great but the tooling to support modern Dev ops is really lacking. This doesn’t matter when learning to code or writing a POC but really becomes an issue when you begin to commercialize products.
[quote=493459:@Julian Mussi]
Also as Norman mentioned…Yes please allow external modules, with classes. This drives me nuts.
These sort of feasible, if not trivial changes, would really allow Xojo to be adopted by more professional users.[/quote]
Oh dont get we wrong I said NOTHING about any of the things that current file format issues being trivial
I suspect to solve some they’d need a completely new, and backwards incompatible, file format
Oh yeah don’t get me wrong, I did say “…not trivial changes…”. Without know all the details I wouldn’t suspect this to be easy. But it seems possible and with some significant benefits.
I’m sure about it. Not file format, just language changes. The file format is text.
Yeah just spit it all out into one giant text file and call it close enough
You know darned well there’s more to it than that
Xcode VS etc do more than that and for Xojo projects there would need to be more than just plopping a pile of text files in a directory
As well I expect it would have implications for licensing since the different versions can / cant read and write text
There’s much more to this than you suspect
And NONE of it requires ANY language changes
In other IDEs, VSCode included, we write texts. Not one giant, but an organized tree of files, some with codes, some with definitions, like XML or JSON. I don’t know from where you take those thoughts out. Obviously there are resources to be consumed inserted in that tree that are not text and we don’t write them, just consume, like an image, sound, or movie file. The language (that explain to the compiler where to find some parts, using language features like “imports”) and definitions (that explain project structures and layouts). Organized. Even where to find resources are explained this way. We don’t have cryptic “tags” floating around the source to make it work because all we need is explained just in code, using the semantics of the language and external project files (texts).
I don’t need “to suspect things” as I know things. Different versions handle its limits by reading definitions of the project (also text), there we say whats necessary to compile. Let’s suppose we make a mistake, an change something by hand enabling a wrong version try to compile something too advanced for it, a different version should give compiler errors about the wrong things it will find. About licensing I have no idea what you are saying. Again, you should try other environments before trying to paint a frame saying that it does not work, as others work. That the current Xojo text is workable for free text programming without changes, because it’s not.
Sure we have some CLI tools to help us “writing” things for us, like creating the project file and adding a basic structure and more, just because it is tedious by hand, like: dotnet new mvc -au None -lang VB , others can do it too.
SARCASM
making the contents of the files text is one small step
how to organize all the files ( directories or not and if so do the directories match up with something in the IDE ?)
trust me there has been a bunch of thinking about this and its not trivial since some choices entail other issues (which is why there are some issues with the exist text project format)
Thomas has filed bug & features requests and I know for a fact I filed others as well as let a bunch of notes and such
Its not just “spit everything out as text and the world will rejoice”