Development Conventions #442
Replies: 1 comment 1 reply
-
Hi 👋 Thanks for writing detailed post! I'll try to give some answers to your questions.
Since Mint is a relatively new language and it's used mainly by early adopters no specific conventions surfaced yet. The only thing which is kind of a convention is the formatter which is a built in feature.
I created the
Mint at it's base is a functional language so it's pretty different form object oriented ones, one structure kind of emerged because of this: we model data using records and enums and then we have a module with the same name as that enum or record which contains functions that work with that, for example the Aside from that, here is a simplified list of the entities an their functions:
I hope this helps! We are working on a tutorial website and this is good feedback which will incorporate into that 👍 |
Beta Was this translation helpful? Give feedback.
-
Hello,
Is there a place where can I find documentation related to coding and naming conventions for the parts composing an overall Mint application?
I was going through this sample application https://github.com/mint-lang/mint-realworld/tree/master/source as I desire to use Mint lang for developing a real-time front-end application which can connect with my back end API and I can use them on production.
So while going through some questions raised in my mind related to development guidelines that have been followed in implementing that sample application.
Stores:
https://github.com/mint-lang/mint-realworld/tree/master/source/Stores
In that folder multiple Stores can be seen defined and each store in its definition seems to be following following naming convention:
Stores.<entity-name>
For e.g
In file https://github.com/mint-lang/mint-realworld/blob/master/source/Stores/Article.mint the store is named as
Stores.Article
In file https://github.com/mint-lang/mint-realworld/blob/master/source/Stores/Articles.mint the store is named as
Stores.Articles
and in this store records are also defined. That raises a question: Shouldn’t records be organised underRecords
folder like stores are organised underStores
as record is an independent concept of a mint application?Another question is there is the file https://github.com/mint-lang/mint-realworld/blob/master/source/Actions.mint which is a store but it is defined outside
Stores
folder. Why? So can anybody’s please explain the reasoning behind such naming styles, code organisation? And are there are any conventions defined for doing so?Also the files or folders under
source
folder follow a naming convention of starting with capital letter for e.gMain
,Api
,Actions
,Stores
(nested folder),Pages
(nested folder) etc so what convention to follow if there a long name which may involve two or more words for e.gMyLongName
? I noticed that in https://github.com/mint-lang/mint-realworld/tree/master/source/Components I can see some examples of such names likeArticle.Comment
,Article.Comments
.So above are some basic questions from the point of view who wants to use the language for developing some production stuff. Are there any recommendations on naming, conventions, code organisation etc by the language team which beginners can follow to start their journey with development in Mint?
And for someone who is already experienced in web development using popular frameworks like Rails or knows about popular design patterns like MVC, can the team provide some analogies between the concepts in those and the concepts in Mint? For e.g can Record be considered as the Model concept MVC design pattern or a Model concept of Rails (ofcourse without the ActiveRecord faciliatated stuff). May be just a PORO (a plain old ruby object)?
In a good web application ideally most of the business logic is implemented in form of services which acts a bridge between a controller and DB to communicate. Can the Stores concept in Mint be considered a service object?
I believe trying to help a newcomer relate the concepts in the new language with the concepts he already knows about from his past development experience it should definitely help in making the newcomer feel at home. I know it might not sound completely realistic because it is impossible for the language team to detail out such things for the variety of audience developers that might show interest in exploring the language but at least for developers coming from few popular backgrounds like Java, Ruby, Python etc it can definitely be attempted just like it is the case with AWS SDK developer documentation wherein they illustrate snippets for Java, Ruby etc languages which one can readily utilise in case that is the language in which one is trying to integrate AWS or ultimately they also provide plain REST endpoint usage example which should not be language specific. Hope you get what I am trying to convey.
Thanks for taking the time to read it through here🙏,
Jignesh
Beta Was this translation helpful? Give feedback.
All reactions