@this that's literally foo ("bar" & bar), baz

I know. I'm flip-flopping here

My ambivalence is because in more complex expression, the extra () can be a good aid in making it readable

wait, maybe I'm doing it wrong.

if one needs () to make it readable, that code is already smelly

and one should refactor so that the expressions are evaluated before calling it.

yes

e.g. myBar = "bar" & bar : foo myBar, baz

MsgBox (foo & bar & baz & twentyOtherThings), vbOkOnly

So, yes, I've made up my mind - we flag it all.

> Consider extracting expression foo & bar & twentyOtherThings into a local variable

^

Are you thinking that we'd use different wording for parenthesized expressions with operators and without?

and we can even have a quickfix for it

@this I think so. no operators is just a literal expression or an identifier -> expression evaluation is fully redundant

with operators, there's a readability concern that you rightly pointed out

Yeah, makes sense

should be separate inspections, to make quickfixing simpler

@MathieuGuindon pardon my probable misunderstanding... I have been treating ByVal as "can't change" and are "single" values, e.g., a row number (As Long) or ubound, and using ByRef for things that "might change" or are "mulitple" values, e.g., a range of cells. Is that some left-field hogwash? I have read a little on .net use of byval (hoping it's the same as vba) being a "topical" pass of a variable as is, at 8 bytes. I haven't found things quite as clear about ByRef (would like to assume treated

as variant at 16 bytes)

sorry it took me a bit to respond to your posting that... was in a quick meeting

> Is that some left-field hogwash?

yep

:)

how does a range of cells change?

it doesn't

it's the properties of the passed Range object that change

but what's being passed regardless of byref or byval, is a reference to a Range object

the difference is whether the scope is allowed to set/assign that reference or not

if it makes sense that a procedure can do Set thatParameter = Nothing and the caller can live with that, then sure, go ByRef

otherwise, when the procedure does thatParameter.Something = 42, whether thatParameter is passed ByRef or ByVal makes no difference whatsoever

except that ByRef is then semantically incorrect

and byval can pass a variant? that was one thing i believe i read on SO that byval was size limited and would cause an error (i did not test, just took at face-value), where byref would need ot be used

yes

well then; thanks for further clarifying those points

I think you're describing a different issue, Cyril.

When you have a ByVal, you can't do implicit conversions anymore

"byval size limit" ...curious where that is

I'm thinking about the error you get when you pass a variant into a parameter that expects a long or a string

requiring you to first convert the variable into appropriate type before passing it in.

tbh the only time ByRef is enforced, is when arrays and UDTs are involved

@MathieuGuindon i've been digging through my history and only see two related posts in my past 6 months: stackoverflow.com/questions/408101/… and stackoverflow.com/questions/290189/… which have links to other sites and the sort... not seeing anything directly related to the allocation size

i might have been mis-recollecting use of int32 in .net with byval because of the discussions and rabbit hole or reading

.net passes everything ByVal by default... works pretty well :)

as docs.microsoft.com/en-us/dotnet/visual-basic/language-reference/… has no related references, i'd be thinking that i can't remember shit

@MathieuGuindon it's funny: in 80s: we'll pass everything by value in C; in 90s: gee, we should save on memory, so we'll pass everything by reference in VBA; in 00s: "screw it, we'll just pass it by value in C#

00s: "we've successfully confused everyone with byref/byval. this was a mistake, ROLLBACK!"

Well, people still get confused because in C#, we have value types and references types, which we can pass by value or by reference.

Thus, in ~2007 Jon writes a treatise on it.

[rubberduck-vba/Rubberduck] retailcoder created comment on issue #1717: Argument to a ByRef parameter is passed by value

I truly believe the single most damaging statement in this department is "objects are always passed by reference"

suspecting Jon's treatise is that dead link at the bottom

hmm yeah. It's now there: jonskeet.uk/csharp/parameters.html

edited

> Your changes are identical to a pending edit

saw that, approved :)

Anyway, lot of information does apply to VBA (or any other languages) actually

yep

One has to do some trnaslation, though. In C/C++ "reference types" would be pointers

ditto for anything OOP - it's just that the VBA crowd tends to heavily constrain their research to stricly-VBA

...where the content is 20 yo

IKR?

I blame it on the large difference in the syntax

they look at C#, go wut? and scurry back to the familiar VBA documentations, even if they're antiquated.

> Objects in mirror are closer than they appear passed by value

@MathieuGuindon @this added my approval

[rubberduck-vba/Rubberduck] bclothier created comment on issue #1717: Argument to a ByRef parameter is passed by value

@Duga ha, nice!

[rubberduck-vba/Rubberduck] bclothier edited comment on issue #1717: Argument to a ByRef parameter is passed by value

@Duga That is not necessarily a functionally equivalent statement.

E.g. for a range foo, Bar (foo) and Bar ByVal foo are very different.

How so?

I found the bastard child.

wait, why range? That wouldn't work.

@IvenBach ARRRGH MY EYES!

There's also Times New Bastard font.

> text-rendering: optimizeLegibility; is top irony

^ Next time someone has a suggestion.

@IvenBach Let's promote Iven... by title only, so more salary, with no additional responsibilies

@Cyril You understood my example from yesterday?

i've looked at it a few times, noting where i need to look up documentation

pulled it out into np++ so slowly getting through it

haven't implemented anything yet; quite a bit to digest

i'll be honest, some of the terms for variables i had to look up, too... e.g., backing field

had never seen that before

@IvenBach I kinda like it

and same as yesterday, this is all related to the subroutine, interface, and class... hven't even attempted to look at the testing procedures (i've never done anything like that, so need to understand a lot of "why" for choosign thsoe specific tests)

I think maybe I'll use that for my email signature...

@FreeMan I'm sure your bosses will love it!

Probably won't ever even notice...

LOL

@IvenBach kind of a conceptual thing, for the interface, you are just putting in read only properties (get), then implements allows the class to take the interface values and utilize, or does the class push those back to the interface? from the printing, it looks like i read from the class and write to the interface

hmm, not quite. you're treating interface as a class, it sounds like.

you remember the 3.5" floppy disk?

yes

on the back, you had a little tab that you could move to make it readonly?

following

so imagine class = the magnetic disk inside the floppy casing

interface = the casing itself

@this The ByVal one should pass the range by value; the parathesized version causes a default member call.

so by switching the tab, you change the capability of what you can do to the class underneath

and each the interface and the class are each their own class modules, yes?

that nomenclature part is part of what's kind of f'ing with my head

yeah, I think that's the other confusing thing - even though you declare both interfaces and classes using class module, you don't use them the same way

In fact, VBA let you use a concrete class like interface, which really shouldn't be so

so it's on you (and us) to not add any code to an interface class module; only define the procedure, and no more.

wtb vba interface module, class module, userform, standard module, sheet module, and workbook module, as default "folders", as opposed to current groupings

then use it to wrap some other concrete class withe actual code.

i feel like that description is key... concrete class versus interface class; because of the implications left by MS' naming convention

@M.Doerner so to clarify - SomeExternalProcedure ByVal myRange would end up passing the pointer to the range object to the externally declared procedure, whereas SomeExternalProcedure (myRange) would get the myRange.Value passed to the procedure?

(I'm not even sure one can use ranges like that in a declare statements... at least not one that is specifically designed to work with Excel's OM)

@Cyril Right -- back to the floppy disk analogy

If I gave you the floppy disk and it didn't have that magnetic disk inside

would that be a very useful disk?

not particularly

Obviously not. That only gives you a empty husk that suggests you could do something with it.

That's your interface; it enables you to maybe read or write from it but without the actual content....

so we have to have an actual magnetic disk within it. That's the concrete.

but I can swap in any magnetic disks i want (assuming I am careful with handling the naked magnetic disk) and it'll all fit in the disk, right?

yes

and when you insert it in, what you can see on the disk will be different based on what particular magnetic disk I gave you in that disk.

the interface looks identical

right and they all work the same way; you insert it into the drive expecting a 3.5" casing.

and I think you can see that I can't take the magnetic disk from a 5.25" floppy disk, cut it down to the size of the 3.5" and put it in the 3.5" casing.

@IvenBach @this would be where the examples reside. looking at the concrete class, it has "get" properties, no "let" properties, same as the interface. As such, I was confused as i thought something had to "let" the value be changed

@this correct

as i typed that, i think i just hurt myself... pretty sure i confused "set" and "let"...

_et... fill in the blank!

will quote chip: "The Get procedure is used to return a value out of the class, and the Let procedure is to put a value into the class". i appear to just be jumbling with the minute, but crucial, difference

Right. so if class defines both get and let but interface has only the get

and you are handed the interface instead of the class, can you write to it?

no

and if each only have get statements, you can't write to either?

Correct. But that's not the key point here.

The key point is that by wrapping the class in the interface, you are basically telling everyone, "you can't write to this. only I can."

i can follow that

That's because you created the concrete class yourself so you have the complete knowledge about the capabilities of the concrete class at that point. But When you're done, and you want to hand it out, you don't want any other code modifying it by accident. Thus, you put it in an interface and give them interface.

That helps all other code "promises" to not modify the property and that can be checked by the compiler

Pop question: which would you rather do the checking -- using the compiler to do the check for you or by your own eyeballs?

compiler

saves me time...

well, in the long run* have to set it up which can be a bit

Thus the whole purpose of the interfaces is to defer as much code-checking as you can to the compiler

you're telling it "I want all consumers to only do x or y but not z on this instance"

copy

That said, it would be unusual (albeit possible) to have a concrete class that did less than the interface promises. But in general, concrete classes usually can do more than what the interface allow but you don't always want any line of code anywhere to do whatever. This is based on the same reasons why we don't want global variables.

just to touch on the concrete class "doing less" than the interface class, would using Implements typically have somethign to do with that? that's the big thing i have been reading about since Iven posted, to understand how that is used and applied

if you have created an interface to read the public properties, maybe the concrete class need only have a function to, say, add together the 5 properties and append that to a string with a 6th property

that's doing more?

by "doing less" I mean that interface exposes a property that the concrete class doesn't need/have

hm? the interface class literally does nothing

Note that when you Implements something, you will be required to implement all members of the interface.

@this sorry, was looking at "doing more" as "having more lines"

My point is that if you find a property on the interface that isn't there on the class, it hints that there is a problem with the design of either interface or class.

not necessarily

But it's generally OK for a concrete class to have additional members that aren't on the interface.

copy

Mind, I'm only talking in general.

"everything in moderation including moderation"; i'm working on relatively high-level concepts to understand, so your general responses and analogies are quite helpful

if there're specifics that are considered outliers, it's not that i'm uninterested, but i can't understand the "basics" then i won't get there, either

it's also ok to have a concrete class expose X (get+let), Y (get+let), and Z (get) through its default interface, and have it implement an explicit inteface that exposes X (get), Y (get), and Z (get), plus A (get) and B (get)

Private Property Get ISomething_Foo does not mandate the implementing class having a Foo property in any way

That is true. If the Foo is somehow calculated, that's usually fine.

However if Foo simply does not exist at all on the concrete class and there's nothing to calculate to arrive at Foo, that might be a possible code smell.

what I mean is, a concrete class' default interface should be designed as per the needs of the (very limited) code that needs to work with that particular default interface

i.e. Class1

rest of the code only sees IClass1

so, IGridCoord might have a ToString method that GridCoord doesn't have, and doesn't need

GridCoord default interface might need a Create method and get+let accessors

IGridCoord just exposes get accessors, and there's no Create method there

@MathieuGuindon But when GridCoord implements the IGridCoord_ToString, what are you going to put there?

If it's empty, that's a code smell, no?

it's not empty, what's in there is a one-liner that returns "(" & X & ", " & Y & ")"

see, you're calculating something

so that's fine.

I'm talking about empty implementation because the interface requires something that the class doesn't have or can't calculate

e.g. it doesn't belong there

@MathieuGuindon - deserve an answer? I was trying to find a dupe using Like but not having much luck

@Cyril Keep in mind this is just an example. I used terms like BackingField because that was hard for me to grok when I was learning. Same thing with my descriptivelyLongNameUsedForTheTopRowRightmostColumnCell that was grabbing a value.

Explicitly using those terms, I thought, would help you understand them. They don't need those names and shouldn't. Adequately descriptive naming for their use.

@IvenBach Understood; trying to follow word choice for the long-teaching descriptions, to me, is important.

Ben's been very kind in helping explain further a lot of the concepts that were throwing me

@this IE Why are you implementing this interface when you can't guarantee you satisfy all its requirements? If you only need a part that may be a code smell indicating either 1) This interface is doing too many things. Split it up. 2) Have you fully thought out your design.

Yes, that.

You wouldn't expect your monitor to have a Print button, right?

@Cyril I'm just regurgitating what they taught me. I've pre-digested for you.

and while certain model of printers might have a Scan button, requiring that all printers support Scan button might be a bit silly

@this #ButItDoes have a PrintScreen option... Nope. Your princess is in another castle.

@this that made me think of touchscreens...

A Scan method belongs on an IScannable interface.

^ for your multifunctional printers, you would probably have MyFancyPantPrinter : IPrinter, IScanner, IFaxer

@Cyril Shhh... Quit blurring the lines. We're sticking with easy things right now.

while you would have MyCheapOPrinter : IPrinter

@IvenBach yeah, i officially need a mental break. "is cannibal" rather than "I Scannable"

That works, too.

@BigBen grrr.. you just made me VTC :)

Have you noticed how those huge ass multifunctional printers tend to eat up other small office machines?!?

well, except for fax machines. That darned thing just won't die.

@Cyril IScannable vs IsCannable are different things. Think about the difference over a nice plate of fava beans with a chianti.

OfficePrinter : IFax, IScan, IPrint, IWillEatAllTheOtherOfficeMachines

it's funny that there's a "fava beans"; considering that "faba" in latin = beans.

so you're almost saying "beans beans"

French brain confirms it totally reads that way

Ha!

Going to try to do my re-cap for things I feel I've learned:
1)  My interface class isn't doing anything but reading (get)
2)  My concrete class is wrapped in the interface class, where cc can Implement ic
3)  Set-up my Interface class to be only what people should touch/interact with
4)  Utilization of the Interface class properties occur in the concrete class
5)  The more appropriate terms "Concrete class" and "interface class" which honestly was something that made understanding very, very hard.

Yep! :-) Sorry about the #5, though.

you'll want to keep the word "wrapped" for something else we'll talk about at another point in the future

in fact I don't understand #2

@this where's freeman to say "blame microsoft" because that feels wholly appropriate

I think he's saying the concrete class implements the interface class.

@MathieuGuindon my fault, probably since I was using that term, based on the floppy disk analogy

e.g. the casing wraps the magnetic disk

#PedanticPete knows how hard naming can be and forgives you.

@Cyril unfortunately, in that case, that's not wholly Microsoft's fault.

@IvenBach TBH I'd rather deal with PedanticPete than Big Bad Pete.

as for "concrete class" and "interface class", part of what's making this harder than it needs to be is VBA itself, and the way classes have a default interface

^

That part is definitely MS' fault

i can rephrase what i understood... User interfaces with my code via the Interface Class; that Interface Class "protects" my Concrete Class, so I was thinking like cell-membrane as "wrapping" to protect my nucleus (concrete class code)

FML oen fo thees dyas lil ralen ot ypte rreccoylt.

@MathieuGuindon What's the default interface?

the concerete class itself

@IvenBach the public members of Class1 define the members Class2 needs to implement if it Implements Class1

With Class1_Foo?

yes

Oh yeah.... Not intuitive at all. Slightly damaging to your brain.

Dim foo As Class1
Set foo = New Class1
foo.<insert member of Class1 default interface here> = 42

in C#, you get a nice clear separation; public interface Foo {...} and public class Foo {...} are two obviously different things.

We've got good teachers at this pond that can overcome VBA's difficulties.

but in VBA, you use Class Module for both and it's on you to remember what's what.

Hence the need for '@Interface annotation.

"default interface" has more to do with the pure-OOP meaning of "interface", i.e. whatever public members an object is exposing

~.~ Sooooo confusing.

and then "user interface" typically refers to a GUI (window/dialog), but in VBA specs and docs "user whatever" means "code written by the VBA dev"

That entire aspect is point #5 lol... i'm still working on use of RD, so will use the '@interface when i make one

the code explorer uses different icons for interface modules

i will say that, completely preferential, the code explorer feels a little cumbersome. Sure I have added a bunch of fodlers, but they're stuck to their VBA projects, so having "General" in 3 VBA projects just add bulk, when each of those only have 1 module within them

it's most likely tied to how i have used my code to date

^^^ pictures/images helped me finally grok this.

Interfaces, Classes, Implements keyword took me ~6 months before they finally :clicked:. Keep at it.

i've got 7 VBA projects in my XLSTART folder, so that's 7x sheet1 modules, workbook modules, and standard modules

i'm really thinking I should go back and consolidate... but that takes time!

organizing code modules is a whole other discussion... one step at a time. once you have a solid understanding of OOP and architectural patterns, what folder hierarchy makes sense for your projects will be much easier

but yeah, we really need some kind of way to quickly "refactor" @folder annotations

My folder structure is pretty weak :sadface:

We need free college Hosch labor again...

That's why having a toolbox with lot of refactoring tools matters more.

I'm guessing folders would be more commonly useful in Access projects, which are more commonly full-fledged applications than, say, Excel or Word projects might be

Otherwise, people will say "ooo, big hairy ugly mess. I shouldn't touch stuff. I'll just put a piece of duct tape here and there and hope for best."

i think it's written in the FAQ that the "folders" are VBAProject specific, which is actually the part that felt cumbersome... because of how i have things load. 7 .xla makes it bulky. Meaning the "folders" aren't the problem, my shit-set-up is!

the parent/top-level node is always the project node

At least for me, I am already up to 17 folders at the top level in one of my project (and some of them have subfolders)

but I still have some dumb folders like Interfaces or Implementations. Those need to die.

I like a Foo.Abstract folder with all the Foo-related interfaces

I started out that way since I had no idea how I wanted to organize things. Only later did it become more clear and I've been moving things out of those dumb folder.

Yes, that's what I have in other folders.

For example, I originally had some stuff in both Interfaces and Implementations which got moved out to SearchForm, ReportGenerator and Email

IOW, the folders are now based on the functional area they specialize in.

But it was not that clear to me in the start. Thus, why refactoring is pretty important; otherwise we'll be too scared to do anything about our uglyballs.

Yeah

Making a MoveToFolderRefactoring is really simple.

The only slightly annoying thing is the dialog to get the name.

Feel better?

lol, quite

@MathieuGuindon just did the dirty work and fixed my 7 xla into 1 xla... world of difference.

@this me thinks most VBA projects are held together with post-it notes an scotch tape. Duct tape seems too rigorous for most VBA users.

now i don't have a mess of VBAProjects and can actually utilize the folders

@FreeMan unless the duct tape is to hold their mouth shut because no one wants to hear/know abotu it

@FreeMan that'd require a copious amount of scotch.

@this 1 bottle should suffice?

either drank or cracked over one's head

more likely a barrel

@this reminds me of willie nelson... "have you ever known anyone who has died from marijuana, Willie?" "As a matter of fact I have... I had a cousin who died when a bail fell on him"

lol

I don't think that's quite what they meant by dying from marijuana.

@FreeMan honestly, I can't wait to see how deep this rabbit hole will go...

managed to nerdsnipe myself at work. fresh from my victory with msix, i've decided to put together a (very) basic internal appstore.

@this Resharper just flags that as "redundant parenthesis", which I think is optimal?

but they don't have the semantic meanings VBA assigns to them

true... they just affect subexpression priority (sometimes redundantly)

I was thinking specifically of the example of foo ("bar" & bar), baz though - that's not doing byval coercion, it's just redundant.

unless I've misunderstood?

i believe it's still doing the byval coerecion

sorry what I meant was, even without the parens there's still an expression to be evaluated, so it's never gonna be sent byref anyway?

This came up by Some notes on transparency in social systems - Shog9. The part about engine trouble codes was a good analogy for abstraction.

Beware the dependency on the meat bags.

Home time.</iven>

alright, time to get out of here; you all have a good weekend

Regarding the parathesized arguments, when it is an object, we already create a result for ImplicitLetCoercion.

@M.Doerner even when it's a part of a bigger expression?

One analogy I came up with for concretes vs interfaces is: the marking stencils that tutors use for multiple choice. The student's paper (the 'concrete') is masked by the stencil (the 'interface'). Thus, the interface presents a particular 'view' of the concrete.

Not a perfect analogy, because presumably the tutor has to at least glance at the paper to check that the student hasn't just filled in every available box, but still...

It's also useful to understand that interfaces facilitate polymorphism, and polymorphism translates to "many forms". Same object, many forms.

@this Then you get the result for where it is used in the larger expression.

I still think the most useful analogy is an electric socket.

Yep that one's good too

public class UnitedKingdom : ICountry, IEuMemberState - there's a PR about to be merged to change that :-)

It's done. The UK is no longer part of the European Union.

breathes massive sigh of relief

</politics>

i don't know enough about it to have a well thought out opinion on it lol

time to look for level 1 issues

hold the phone

VBA supports long pointers?

Yes?

i just didn't expect that it would

well, how would possibly a language without pointers work?

like how - from what i understand - working with pointers in c# is frowned upon

well it does hide the users of VBA from the pointers but it's still there

yeah that's more what i was getting at, but didn't communicate it well; i was surpised that VBA exposed pointers to the users

well, it does goes without saying that once you start chasing pointers, you've left the sandbox of VBA

yeah exactly

@this IIUC webassembly is entirely stack based?

I guess to prevent sandbox escapes

but I take your point, it's... limiting.

@jcrizk VB(A) is way more powerful than you might think. It has the potential to access anything. Hence the "macro virus" fun from back in the day...

It can even do inline assembly...

@mansellan oh, i wasn't implying that it's not powerful. i just expected pointers to not be exposed since - from what i understand - it's meant to be used by people who aren't too familiar with programming

well, it doesn't make them obvious, but they're there. Just check AddressOf.

like, i don't think that it was designed with catering to the same group of people similar to the developers who developed VBA

VBA came from VB, which was a general-purpose Win32 language. They really didn't limit it much, other than preventing entry points outside the host.

Perhaps they should have, see "macro viruses".

but would VBA have been as useful to people if they couldn't automate stuff outside the host, though?

It was more useful than they expected

^

it's 7 years older than me lol

RE: stack-based; I don't know enough but at the end of the day, it's still 0s and 1s, so there's gonna be pointer chasing. You can pretend it's not there and all but it's still there.

lol yeh

kind like how a nasty person doesn't magically disappear if you cover your eyes and ears and shout LA-LA-LA!

@jcrizk not so much frowned upon as guarded. You have to make a conscious choice to leave the managed environment, kinda like "here be dragons".

i still have no clue what the difference is between reference types and pointers; it's something that's on my list of things to do that i never get to

not sure I like their choice of keyword being unsafe tbh. unmanaged would have been a better fit IMO.

@jcrizk reference types are on the heap, so you have a pointer to where they are. that's it really.

@mansellan lol what the hell, that's it?

i figured as much tbh

yep. value types you have right here. reference types you have the location of.

oh man, trust me. i had to learn what value-types were fast while working with matlab lol

i was really surprised that matlab even supported OO

protip: keep structs small. they're value types so they get put on the stack, and get moved by copy.

usually get put on the stack...

funny thing is that the other intern in the office was wondering why his changes really slowed down his testing. turns out that it's better to pass references to giant matrices instead of copying them over and over again

lol yep

> you mean i need to make a class just so i can pass this? ugh!