Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment   Page 2 of 3      Prev   1   2   3   Next
Burillo

Avatar / Picture

Registered:
Posts: 329
Reply with quote  #16 
Quote:
Originally Posted by Shabazza
It's a commonly accepted code rule to start method names with lower case and class names with upper case.
For C, C++, C#, Java and a bunch of other languages. So this is a point that irritates me in the API that they use upper case for methods.
Plus there really should be direct public methods to modify stuff. .enable(), .close(), .setLock(true).
I expect this from a C# based API.

Microsoft disagrees with you. the whole .NET API is capitalized.
phoenixcorp13

Avatar / Picture

Registered:
Posts: 524
Reply with quote  #17 
Quote:
Originally Posted by Shabazza
It's a commonly accepted code rule to start method names with lower case and class names with upper case.
For C, C++, C#, Java and a bunch of other languages. So this is a point that irritates me in the API that they use upper case for methods.
Plus there really should be direct public methods to modify stuff. .enable(), .close(), .setLock(true).
I expect this from a C# based API.

If you have a proper documentation you can cope with a sting based operation/attribute set.
But the official docs are not sufficient yet. Without infos drawn by the community about block properties and actions,
we would not be able to do anything useful with the programming block by today.
We have ".ApplyAction(IMyTerminalBlock block, string actionName)" in the API docs. Fine. Now what? [rolleyes]
steam have list of props and actions.
yes sometimes they miss something, but we all people and can make error.

about what you saw in another langs, like Java and C++(atm they don't have props, so set/get is usual notation).
We, Russians have proverb:
в чужой монастырь со своим уставом не ходят
Don't go into somebody else's monastery with your own set of rules.

С# have it's own rules, so use them, don't take your own rules into another territory.


Brenner

Avatar / Picture

Registered:
Posts: 407
Reply with quote  #18 
Quote:
Originally Posted by Shabazza
It's a commonly accepted code rule to start method names with lower case and class names with upper case.
For C, C++, C#, Java and a bunch of other languages. So this is a point that irritates me in the API that they use upper case for methods.

As everyone else already said .. nope. In .NET the commonly accepted code rule is having class names, property names, and methods always start with a UPPER case letter.
Quote:
Originally Posted by Shabazza

Plus there really should be direct public methods to modify stuff. .enable(), .close(), .setLock(true).[rolleyes]

Aside from the lower case / upper case topic I agree.

It would be better to have methods like "Open()" on doors instead of the silly ApplyAction("Open_On")

Also, real .NET properties instead of the SE only concept of "Terminal Properties". 
Instead of having to call GetValue("Color") or SetValue("Color",yourColor) to get or set the color of a interior light, you could simply write yourColor =  block.Color or block.Color = yourColor respectively. 

Internally those new methods and Properties could still call the appropriate "ApplyAction" or "GetValue" or "SetValue" - they could be pure wrapper functions.

I think this would make the source code way more readable, the automatically generated API Documentation way more useful and you would get more compile time errors as opposed to runtime errors. Compile time errors are always preferable, less testing and error searching that way.


TheGrimReaper

Avatar / Picture

Registered:
Posts: 26
Reply with quote  #19 
Quote:
Originally Posted by LordDevious
-snip-

I have Java's Pro Certification. And although I'm not certified in C++, I use it every day at work.

Quote:
Originally Posted by Brenner
-snip-

Alright, now that a lot of us agree that we should have actual methods/functions to operate blocks and actions, instead of using Strings, how do we get Keen to accept this?
LordDevious

Avatar / Picture

Registered:
Posts: 998
Reply with quote  #20 
Quote:
Originally Posted by TheGrimReaper

I have Java's Pro Certification. And although I'm not certified in C++, I use it every day at work.

I don't question your skills. I have been doing this for a very long time and with a lot of different languages, including C++ and Java, and I have always stuck to whatever standards were applicable for whatever language I was using at the time.

As to the question at hand: I doubt that Keen will be making big changes now that the block has been released, unfortunately. Sure, they will be giving access to more stuff, but I have a hard time believing they will change the basics of the API. Which is a shame, really, because I believe it will scare newbies away from programming, make them think that it is harder than it really is.

All we can do, I think, is keep bringing up these kinds of threads, and hope they'll listen.
TheGrimReaper

Avatar / Picture

Registered:
Posts: 26
Reply with quote  #21 
Quote:
Originally Posted by LordDevious
Quote:
Originally Posted by TheGrimReaper

I have Java's Pro Certification. And although I'm not certified in C++, I use it every day at work.

I don't question your skills. I have been doing this for a very long time and with a lot of different languages, including C++ and Java, and I have always stuck to whatever standards were applicable for whatever language I was using at the time.

As to the question at hand: I doubt that Keen will be making big changes now that the block has been released, unfortunately. Sure, they will be giving access to more stuff, but I have a hard time believing they will change the basics of the API. Which is a shame, really, because I believe it will scare newbies away from programming, make them think that it is harder than it really is.

All we can do, I think, is keep bringing up these kinds of threads, and hope they'll listen.



I know you weren't questioning my skills, I was just expressing the experience that I mostly have, which, C# isn't in that list. 

I really wish I could like, or upvote your post. Maybe if we create separate threads for each update of the API, maybe that'll do the job we need to get their attention.


Two

Registered:
Posts: 87
Reply with quote  #22 
Quote:
Originally Posted by LordDevious
However, what is important with coding standards is simply to pick one and stick to it. Whether you use upper or lower case letters in your identifiers is irrelevant as long as all your code in that perticular language does.

Coding standards have not been invented so the code looks pretty, they exists to assist coding. Java has set a standard here, that has been accepted widely because it makes a lot of sense. Yet MS - as so often - does things different just to do things different. Capitalizing function names does not help in any way, it is just to say "Look we are not like the others!". If people do not accept that standard, then probably because it's bad.

Quote:
в чужой монастырь со своим уставом не ходят

That totally made it in my top-ten list of quotes. [biggrin]

So why are properties bad?
Because I, the programmer, have no clue what happens when I use them. In fact I don't even know that I am using properties, because they look exactly like public variables. Now in a world where everyone is smart and no programmer ever makes mistakes, this is not an issue at all. However as soon as we leave that world and enter the real one, you will sooner or later stumble upon code, where properties are manipulated frequently, despite the fact that each change causes a huge and costly chain of events. Simply because the caller did not realize he was actually calling a function, nor did he ever test his code. And the author of the property didn't know that you should not make them expensive.

You cannot make everyone smart, so make sure your code is fool-proof.
fabricator77

Registered:
Posts: 242
Reply with quote  #23 
Your really not getting it...

Easily copes with adding/removing actions, eg modded blocks
((IMyDoor)Var).GetActionWithName("Open_On").Apply(Var);

Doesn't cope with changes to actions.
((IMyDoor)Var).Open_On();

If say Keen decided to remove Open_On (or rename it), then the later method would break/crash existing scripts, where as using a string you could always alias it.

I for one like Keen's existing API, as at least they have considered modded blocks and changes. The IMyDoor stuff is annoying, as the full script API doesn't require it. Still annoying limitations at times, eg Beacon range is read only.

I'd much rather Keen spend their time on actually adding things to the API modders have asked for, than on some half baked rewrite of everything based solely on programming theory (and not so much reality).
phoenixcorp13

Avatar / Picture

Registered:
Posts: 524
Reply with quote  #24 
Quote:
If say Keen decided to remove Open_On (or rename it), then the later method would break/crash existing scripts, where as using a string you could always alias it.
if they change it they will broke both scripts with actions and with methods.
one will fail at execution, second will fail on compilation and scripter will see exact reason of fail, not mythical NullReferenceException.
Quote:
I for one like Keen's existing API, as at least they have considered modded blocks and changes. The IMyDoor stuff is annoying, as the full script API doesn't require it. Still annoying limitations at times, eg Beacon range is read only.

Range is not read only.
you can set it via SetSingleValue by name Radius

TheGrimReaper

Avatar / Picture

Registered:
Posts: 26
Reply with quote  #25 
Quote:
Originally Posted by fabricator77
If say Keen decided to remove Open_On (or rename it), then the later method would break/crash existing scripts, where as using a string you could always alias it.


There is something in Programming, known as Deprecation. *Coughs* link *Coughs* Basically their compiler can (should) give warnings that there has been a new method of doing something, and what ever they are using (show line) is deprecated and to switch to the new method of doing things. 

TL;DR:
Add a new method, deprecate the older one, remove the older one much later.

I'm not asking to just remove the old way of handling blocks, just add a new, better way, and deprecate the old way, which is the correct way to maintain public APIs.


Quote:
Originally Posted by Two
You cannot make everyone smart, so make sure your code is fool-proof.

I completely agree with this statement, and I am probably going to make this my sig.
Thorium

Registered:
Posts: 5
Reply with quote  #26 
I think they used the wrong language for the programmable block.
If you want a very easy to use scripting language for gamers is C# really the way to go?
I think they used it because they use it to develop Space Engineers and not because it's the best choice for a scripting language.

They should scrap C# and go with a very simple Basic dialect. Easier to learn, easier to write, easier to understand. Remember this is for gamers, not only for programmers.
Cy83r

Avatar / Picture

Registered:
Posts: 68
Reply with quote  #27 
Ah, I've taken programming course and I barely comprehend what's being discussed right now.  How simple is Python compared to full-on C-languages?
TheGrimReaper

Avatar / Picture

Registered:
Posts: 26
Reply with quote  #28 
Quote:
Originally Posted by Thorium
They should ... go with a very simple Basic dialect.

Basic and most if not all of its dialects suck, and Keen needs to go with something more modern, ie: Ruby, Python, JavaScript, Perl, AnyRealScriptingLanguageThatIsControllable.


Quote:
Originally Posted by Cy83r
Ah, I've taken programming course and I barely comprehend what's being discussed right now.  How simple is Python compared to full-on C-languages?

Actually, I was thinking about Python, and I think it would be pretty good. That or JavaScript, because both of them are limited to what Libraries you allow, and have native types like int and char and so on and so forth. I have been using Python for Raspberry Pi projects, and I really do enjoy it. Easy to learn, easy to read. My only complaint about the Python language is that I hate its syntax, but that is only because it is different, not because it is bad.

My vote is for Python if they change the scripting to an actual scripting language.
LordDevious

Avatar / Picture

Registered:
Posts: 998
Reply with quote  #29 
Quote:
Originally Posted by Two
If people do not accept that standard, then probably because it's bad.


Except it is accepted. All official APIs for .NET that I have ever seen has been capitalized. I don't understand what the big deal is. Like I said, I have been programming for more than 25 years, and I have always matched whatever standard is widely accepted for a language. And coding standards are not only for assisting coding, it is also for improving readability, especially where several developers are involved with the same code. I honestly don't disagree with you that it should have been lowercase, but that is irrelevant because that is not what is common for this language. It took some time for me too to get used to. That's what Resharper is for [wink]

Quote:
Originally Posted by Two
So why are properties bad?

Which is why it is considered bad practice in C# to ever expose variables without a property implementation, except on simple structs. The C# compiler is pretty clever with what IL it generates, so it's no problem. .NET developers commonly have learned to think differently than a C++ developer, because much of what is needed for C++ development is simply not important when programming C#.

Quote:
Originally Posted by TheGrimReaper
My vote is for Python if they change the scripting to an actual scripting language.

In theory they could add support for something like Boo or IronPython which is already designed to work with .NET. But I doubt they will ever add anything which needs an abstraction layer.

But I severely doubt there will be any change to the language.


TheGrimReaper

Avatar / Picture

Registered:
Posts: 26
Reply with quote  #30 
Quote:
Originally Posted by LordDevious
Quote:
Originally Posted by Two
So why are properties bad?

Which is why it is considered bad practice in C# to ever expose variables without a property implementation, except on simple structs.


Using methods to interact with fields is better than using properties. Here's some reasons why (I was too lazy to paraphrase so for the sake of this post I copy, pasted, and quoted, plus I am tired).

Quote:
Originally Posted by Programmers.StackExchange.com

Why use methods instead of properties?

  • No performance guarantees. The API will remain truthful even if the method gets more complex. The consumer will need to profile their code if they are running in to performance issues, and not rely on word-of-API.

  • Less for the consumer to think about. Does this property have a setter? A method sure doesn't.

  • The consumer is thinking from a proper OOP mindset. As a consumer of an API, I am interested in interacting with an object's behavior. When I see properties in the API, it looks a lot like state. In fact, if the properties do too much, they shouldn't even be properties, so really, properties in an API ARE state as they appear to consumers.

  • The programmer of the API will think more deeply about methods with return values, and avoid modifying the object's state in such methods, if possible. Separation of commands from queries should be enforced wherever possible.



OH, and while I'm at it, here is a KeyNote about creating a proper API.



It's more than just a "Theory". Its completely possible. And yes I doubt they will do anything to the Scripting or API any time soon (or possibly ever).
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!