|
Actually, the "friendly manual" isn't answering his question. It only confirms the statement in the assignment that you cannot add any parameters after the params keyword, but not why! 
Unless of course "B'cause Microsoft says so!" is an acceptable answer to the question... 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
- because the compiler forbade it?
- because
Method<T>(params T[] values1, params T[] values2, params T[] values3) is a problem and hassel to understand without benefit?
|
|
|
|
|
Because params is an array of undetermined length.
If you write:
void Foo(params int[] ints)
and try to call it with:
Foo(1, 2, 3, 4)
How would it know that you want 4 as a separate argument, if the method were defined like this:
void Foo(params int[] oneThroughThree, int fourth)
OK, maybe it could use type information, but that leads to bottomless pits where the Wumpus will eat you.
Marc
|
|
|
|
|
Homework Marc. You're doing his homework for him.
|
|
|
|
|
Dave Kreskowiak wrote: Homework Marc. You're doing his homework for him.
Oh well. 
Marc
|
|
|
|
|
|
What part of "in YOUR own words" do you not understand?
When the tests come around do you get to go on the 'net and ask people for the answers?
Congratulations on failing your class!
|
|
|
|
|
Nice try, but
void Foo(params int[] oneThroughThree, int fourth) would need to be called like this:
Foo(new int[] {1,2,3},4);would it not?
Software Zen: delete this;
|
|
|
|
|
Harbie wrote: Explain in your own words why you cannot pass additional arguments in a function after using the params keyword.
The lily
Abruptly changing
The orange, having changed already
Moon pie.
(I certify that these are my own words.)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
|
I bet Jon Skeet can have additional arguments after a params arg.
|
|
|
|
|
The VBA interface doesn't allow it.
|
|
|
|
|
Because if you could you wouldn't have homework to do.
|
|
|
|
|
Not sure how C# implement that, but I'm guessing it has to do with how the arguments are push onto a stack before a function address is invoked. Being that the stack doesn't have anything to manage what type each parameter are and the Parameter type can be any number of arguments, making it difficult to separate the actual arguments from the Parameter ones.
|
|
|
|
|
Examples of duck-typed, script languages:
Javascript  (what, me biased?)
Ruby
Python
Examples of statically typed compiled languages:
C
C++
C#
Go
This isn't a question of which you think is better (I know, the answer is "it depends") but feel free to answer that question, and why (particularly what it depends on).
My question is, if you were asked "how should I start learning programming?" would you a recommend duck-typed script languages or statically typed compiled language? Does it depend on what age the person is (for example, your kid, vs. a coworker interested in programming)?
Which would you prefer to teach to someone new to programming?
Why am I asking this? Because several sources of Python that I've encountered consider it a good learning language, and I'm curious what the experts here think!
Bonus (virtual) points for whether you'd pick an imperative programming language or a functional programming language!
Marc
|
|
|
|
|
Do I have to pick one of those?
I'd start with assembly. It's structurally simple and easy to learn incrementally. "Literally a list of instructions" is the simplest model to get used to.
|
|
|
|
|
harold aptroot wrote: Do I have to pick one of those?
Nope. 
harold aptroot wrote: I'd start with assembly. It's structurally simple and easy to learn incrementally. "Literally a list of instructions" is the simplest model to get used to.
That's a really good point -- I've always thought that a person learning programming should begin with what the processor is doing.
Marc
|
|
|
|
|
Marc Clifton wrote: That's a really good point -- I've always thought that a person learning programming should begin with what the processor is doing.
Than one can also argue that before learning what the processor is doing, they should learn about how it works and digit circuit design (AND gates, OR gates, Multivibrators, FlipFlops, FIFO, LIFO, etc...).
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Marc Clifton wrote: I've always thought that a person learning programming should begin with what the processor is doing.
I think that makes C a nice learning language. It is based on a fairly low-level processor abstraction.
Of course, it is like teaching your child how to cut their food using a chainsaw...
Software Zen: delete this;
|
|
|
|
|
Dude, I can't tell if you're serious. Because if you are, I'd say, "YIKES!" (and more below).
If you're not, then I'd be happy to pile on with more helpful suggestions, like "Forget Assembly. If you really want to dip your toes in the water you should start out with machine language -- go straight to the binary, so you can really understand the way the computer thinks!"
...And if I really have to explain my "YIKES" comment...
Assembly is a marginally useful language to explore for advanced coders. It is absolutely NOT what beginners should be introduced to. That's like giving entry-level math students a calculus book.
Seriously. Yikes. Please never teach an intro course.
|
|
|
|
|
I actually am serious. I don't disagree about the low relative usefulness. Of course assembly is not a convenient or easy-to-use language.
But none of that matters. At its core, assembly is simple. Literally a list of instructions, that is something everyone immediately understands. The syntax is trivial too. What people have trouble with is decomposing problems into the right parts, which is a bit harder in assembly. But you can jump right in. Other languages suffer the problem that in order to do anything (or even read anything), a lot of pointless syntax and other magic incantations have to be learned.
kdmote wrote: Seriously. Yikes. Please never teach an intro course.
Too late. I'm a teaching assistant for a computer architecture course. First year course, straight to assembly (architecture too, of course). They also learn Java in parallel, where they get confused about declarations and types, many stay confused until they take a course in compiler construction. Almost no one is fundamentally confused about assembly, they just find it hard to use.
|
|
|
|
|
kdmote wrote:
That's like giving entry-level math students a calculus book.
I would strongly disagree. It is much more like teaching them the basics of arithmetic by hand before letting them use a calculator.
|
|
|
|
|
Don't agree... There is a reason people don't use GOTO in c anymore... Assembly is a whole bunch on GOTOs with some non-portable code.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
Yes, but that reason was that it doesn't scale to large programs and is in general hard to use, not that it's hard to learn or to at least understand the fundamentals. The point of a first language is not writing large programs in it so that aspect doesn't matter.
|
|
|
|
|
If someone were learning to program I would recommend they start with Scratch - that way they get to understand the mechanics of programming (loops, variables, conditional branching) before they get bogged down in syntax.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
