« first day (1901 days earlier)      last day (33 days later) » 
00:00 - 19:0019:00 - 00:00

12:00 AM
@this Tried searching for the error message and "NUnit & Nunint3TestAdapater nuget packages and it's all good" as you said should be the answer. Contacted the author and hopefully I get a response. Thanks for your suggestions.
 
in any case, I don't think RD having it as a module vs class makes any difference for RD
 
FWIW, I decided to go with mock2 = mock1.SetupChildMock() seems more natural.
 
if it helps us to have it as a module, then by all means let's have it as a module
 
all mock now have to track the provider but it's not disposable so hopefully will be OK
 
RELOAD!
[rubberduck-vba/Rubberduck] 2 opened issues. 15 issue comments.
[Minesweeper] Games Played: 63, Bombs Used: 52, Moves Performed: 8528, New Users: 15
 
12:01 AM
@this what happens if user code attempts to mock the mock provider?
 
Yeah, I agree that from RD's POV, it doesn't matter but it might be more helpful to the users to pretend that Debug is a module. As you said, satisfies the non-object nature of Debug.
 
but contradicts docs
 
@MathieuGuindon Rubberduck enters Rubberduck?
 
I vote for a failed test with a "Quack! Don't mock me!" message =)
 
I guess I should put in a guard to prevent them from trying to mock the mockprovider - that is utterly nonsensical.
LOL, love it!
 
12:03 AM
we have similar easter eggs with the fakes
 
come to think of it, none of the COM-visible types should be mocked. I don't want to deal with this at all.
 
yup. needs to be explicitly guarded against
 
fortunately, MockProvider is the only place where we create mocks, so it's easy to put in a guard clause.
 
Thinking we're about to need new test templates that showcase/demonstrate how fakes and mocks can be used
...and docs
It's too early to blog about mocking is it?
yes mug, until that PR is merged, NO ONE uses mocks in VBA
 
12:16 AM
@this I think it's fine to mock the experimental API stuff, e.g. Declaration and IdentifierReference
 
12:27 AM
To be clear, I mean in that particular namespace
I'm still refactoring - I finished refactoring the mock & setup. I'm now refactoring the type cache.
 
[rubberduck-vba/Rubberduck] build for commit 28fa90f4 on unknown branch: AppVeyor build failed
BUILD FAILURE!
 
(and that's where I realized the gap w/ the child mock since the Scripting.Drives has no prog ID and thus cannot be created directly)
RE: docs & examples, I would love it if someone else took it up. That would be also be a good way to test the mocking and catch my bad assumptions/preconceptions
 
I must write about this
 
:+1:
I'll push as soon as I can. :)
 
this PR is bloody awesome functionality!
 
12:36 AM
yes, it makes so many more code testable - have a function that takes or returns an Excel.Range? No problem!
 
it's a real game changer
 
TBH, that was also a big roadblock for me to write unit tests in my VBA code -- too many things needs objects and it is not always practical for me to create abstractions and it also helps with documenting legacy code that needs to die
 
exactly
and no other add-in - for now - enables that, either =)
(right?)
 
NAFAIK.
we're visiting moon.
 
 
2 hours later…
2:47 AM
Dont let the bubbles out while coding. It all makes sense now.
 
So in the end @this your confident to check all aspects of Access controls later you need when you mock them, right?
 
 
3 hours later…
5:41 AM
@pond poll regarding unit tests. Arrange Act Assert is the format of tests. Because I’ve been following RD I’m accustomed to Assert.FooBar( expected, actual ) instead of Assert.FooBar( 0, duk.DukGo ) which uses a member access. Is this more of a pond centric convention or is it used by other coders out there as well?
Besides being a strict comparison helping to avoid unforeseen issues with member access is there other reasons why this is done?
@this regarding the Arranger Pattern, for lack of knowing what to call it, would you consider that a subset of a factory method that’s just highly specialized?
Night pond.
 
 
1 hour later…
7:06 AM
@IvenBach I put the actual and expected in variables for debugging convenience. It is sometimes really hard to get at the tooltip in the debugger for member accesses.
You can see the direct comparison in the test result, but sometimes that is not enough.
 
7:30 AM
> **Rubberduck version information**

Version 2.4.1.4627
OS: Microsoft Windows NT 10.0.17763.0, x64
Host Product: Microsoft Office x86
Host Version: 16.0.11901.20218
Host Executable: MSACCESS.EXE

**Description**

I am looking for a tool that can help me refactor controls on an Access form.
There is no Rubberduck menu when I right-click on a control on a Access to rename it. (I've seen a screenshot like this for an word/excel userform though).

If I right-click on a control like thi
 
 
3 hours later…
10:18 AM
> Thank you for reporting! You raise up great questions.

1) Rubberduck is a *VBE* add-in and is meant to be host-agnostic. As such it does not directly deal with host. Access forms, reports and controls are a part of Access, not a pat of VBE, and to do something like rename requires interaction with the host, not with VBE -- renaming the contrls in the VBA code only would not be enough.

2) The ability to recognize a control as a control is on our todo list. In particular see [this project
 
11:01 AM
> Thanks for your fast reply and the thorough explaination!
Sorry that I missinterpreted Rubberduck, but it is great that a feature like this may be possible in the future :-)

Do you know by chance of a Access add-in which would allow me to refactor Form controls like I intended?

Thanks and regards
 
 
1 hour later…
12:03 PM
@PeterMTaylor Yeah that'd be one of the goals. The other goal is to set up tests for legacy code without changing the legacy code. Can't really refactor if you can't prove that the refactoring didn't break something.
@IvenBach Yeah. It is kinda similar to the static factory method, except we obviously don't keep it on the class itself because it only applies to the tests, not so much for production use. The idea is that if you author 100 unit tests for a class that only need new duck(), it'd suck if you realized down the stream that you needed to add something to the ctor so it's now new duck(ducklings). For those 100 unit tests you already wrote, they didn't really care if there are ducklings or not.
With the static arrange pattern, you simply add a new overloaded version and have your original 100 unit tests call the parameterless arrange with generic new Mock<Ducklings>.Object passed into the ctor for the Duck's and you can then write new unit tests that inject a specialized Mock<Ducklings> to test something about the interaction between the Duck and the Ducklings
 
Really, the static part does not matter. The arrange method simply extracts the responsibility to construct the class under test.
 
12:20 PM
That's true.
 
12:32 PM
> Unfortunately, no. I know there are add-ins that helps with renaming controls in userforms (e.g. MZ-Tools) but I am not aware of any Access add-ins that helps with the refactoring from Access.

However, I can give you an advice that might help in discovering them -- It looks to me that we have expressions like `Me![Text123]` which makes the code late-bound and therefore unverifiable. If you convert all `Me!` into `Me.`, and strip away the brackets so that it becomes `Me.Test123`, then you c
 
Basically, to avoid that the amount of tests starts to hamper adaptability of the code, the structure of the tests has to improve as well.
Using an arrange method is the first and öfter the final step.
For classes with more varieties and similar tests, like the quickfixes, we go one step further and use an abstract base class that already contains the main part of the test execution.
@Duga I have my doubts that Me!Whatever is late-bound.
 
Perhaps not literally but for the purpose of compilation it is
Me!someControlThatDoNotExist will not generate a compiler error.
 
As long as the class/form has a default member, this will statically bind to it with the argument "Whatever".
 
at runtime
 
No, default member binding happens at compile time.
 
how can foo!IdontExist compile then?
 
> **Justification**
When replying to #5092 I thought we already had a request for this refactoring but was surprised that there wasn't.

The proposal is to have a simple refactor that converts all bang operators into dot operators -- there is no legit reason to use bang operators, especially on `Me` on the LHS. The refactor should expand the expressions (e.g. Access' form's `Me!Foo` should become `Me.Foo` which is more descriptive of what the code is actually doing and more importantly makes
 
Only if a Variant or Object is involved, runtime binding is used.
 
@M.Doerner Well, as noted in the #5093, Access form allows for dotted access to controls directly which beats the access via the collection which is always evaluated at runtime.
 
That is foo.DefaultMember("IdontExist").
 
12:44 PM
^
but we should use Me.foo instead of Me.Controls("foo")
which is the point I'm making.
Both are equivalent but only former will be validated at compile-time.
 
> Thanks for your reply!

I recently inherited a very old and big codebase which unfortunately uses the bang operator and the default generated control names a lot - so there are LOTS of controls named like text1 - text999 on ONE form.

A automatic refactoring process would have been great for that, but I guess I have to manually fix it step for step over time.

Thanks and regards
 
The userforms work like that, too, right?
@Duga poor soul
@this Yes, they do.
 
> Addendum: the userforms also have the same behavior so it is obvious that there is a feature that enables the container to support member access via dot operator to the collection members. For the refactoring to be most productive, we'll need to be able to recognize when the container (be it Access Form/Report or Userform) can make dotted access and refactor toward that over the collection unlike the case of recordsets.
 
I really thought Thunderframe opened an issue like that but I couldn't find it. :\
 
1:30 PM
You know, RD has a lot of awesome features, but the unit testing fakes/mocks are the most awesome ones of all.
Although, my personal favorites are the grammar/resolver.
Not for working on, but for the most impressive and complex pieces.
For working on, I like refactorings and inspections.
 
@MathieuGuindon no, Mug, PR or not, everyone mocks VBA - justified or not
@M.Doerner Umlauts make everything better! :)
In my ApptPlusWebDownloader.cls, I have:
Private Type TInfo
  siteID As DownloadDataType
  Browser As Browser
  LinkKeys As LinkKeys
  Url As String
  UserID As String
  Password As String
  CallingLocation As String
  Driver As Selenium.WebDriver
  IsLoggedIn As Boolean
  IsPageLoaded As Boolean
  SiteValues As Scripting.Dictionary
  SiteValue As String
  DestinationPath As String
  fileName As String
  DeleteExistingFile As Boolean
  TimePeriod As DownloadTimePeriod    `<-------
End Type
Public Property Get TimePeriod() As DownloadTimePeriod
  TimePeriod = this.TimePeriod
End Property
Public Property Let TimePeriod(ByVal Value As DownloadTimePeriod)
  this.TimePeriod = Value
End Property
In other code, I have
  Dim Downloader As IWebDownloader
  Set Downloader = ApptPlusWebDownloader.Create(Chrome, ApptPlus)
  Downloader.TimePeriod = Form_DataMove.ApptPlusRunFrequency.Value
but I get a compiler error claiming "TimePeriod method or data member not found". RD can see it and parse it just fine. What the heck am I missing?
Heck, I even restarted Access and did a C&R, just to be on the safe side. Still doesn't like it
I can do ` Downloader.DeleteExistingFile = True` w/o a compiler error...
 
2:06 PM
@FreeMan is TimePeriod on the IWebDownloader interface?
 
unrelatedly re: the typography discussion a while ago:
 
> Wouldn't that just be the default member? UserForm.Controls and Recordset.Fields aren't all that different.
> Both are default members, yes but last time I checked rs.SomeField is a compile error whereas frm.SomeControl isn't. In the latter case, it's obviously doing some extra to enable the dot access on the member (e.g. adding the controls to the interface dynamically). Recordsets never exhibit that behavior. In the cases of forms/reports/userforms, I suspect that being persisted, they can dynamically update the interface and thus expose the members directly on the interface, whereas recordsets
 
@Duga oh
takes a sip of caffeine
 
> Both are default members, yes but last time I checked rs.SomeField is a compile error whereas frm.SomeControl isn't. In the latter case, it's obviously doing some extra to enable the dot access on the member (e.g. adding the controls to the interface dynamically). Recordsets never exhibit that behavior. In the cases of forms/reports/userforms, I suspect that being persisted, they can dynamically update the interface and thus expose the members directly on the interface, whereas recordsets
 
2:22 PM
we've been treating form controls essentially as WinForms does: hidden Public WithEvents ControlName As ControlType fields
it certainly feels like that's what VBA does, too
 
yeah, it has to. It's not magic pixie dust.
It's the "how do VBA know that?" part that I am not 100% sure. I don't think it stops at forms.
 
@MathieuGuindon argh, no it isn't...
 
@FreeMan Incredible as it may be, sometimes the error actually means what they mean!
 
@this say it ain't so!
 
> A counterexample --

```
Dim c As ADODB.Connection
Set c = New ADODB.Connection
c.foo
```

This compiles (but yield a runtime error unless I actually connect to some source that has `foo` as a procedure or something. However, unlike the `frm.SomeControl` case, there is _no_ intellisense downstream from the `foo`. Note that by default, all COM interfaces are extensible -- to disallow dot access on random members, the interface must use the [`nonextensible` attribute](https:
 
2:32 PM
@FreeMan what? say it yourself!
 
@FreeMan Dim Downloader As IWebDownloader determines what lens you're seeing this object through.
doesn't matter that it's a ApptPlusWebDownloader, it could just as well be a FakeFooDownloader
 
Now I've added it to IWebDownloader, and I've added it to the other implementation, but it's complaining that I haven't:
 
shouldn't it be IWebDownloader_TimePeriod?
 
brb...
None of the other properties are, and they've compiled & executed just fine for the last year+
 
maybe I'm confused. If you added TimePeriod to the interface IWebDownloader, then the implementing class should have IWebDownloader_TimePeriod
 
2:39 PM
@this yes
@FreeMan because you haven't ;0)
 
Or because you have it exposed both way (e.g. Foo and IWebDownloader_Foo somewhere down)?
 
@FreeMan use the codepane dropdowns. select IWebDownloader on the left side, and the right-side dropdown will show you all the members you need to implement
 
#ProTip: Implement it all.
That said - I'm iffy on the idea of exposing properties both on the class and via the interface. I'd rather have a single implementation and do the necessary casting to access the interface.
Not sure if that's the case w/ freeman's code but just wanted to go on the record
 
correct. ApptPlusWebDownloader.TimePeriod only needs to exist if the TimePeriod property ever needs to be accessed from ApptPlusWebDownloader's default interface - could be the case for a factory method, but then IWebDownloader probably doesn't need to expose a Property Let member for the TimePeriod property.
 
I'm seriously bumfoozled... In IWebDownloader.cls:
Public Property Get DeleteExistingFile() As Boolean
End Property
Public Property Let DeleteExistingFile(ByVal Value As Boolean)
End Property

Public Property Get TimePeriod() As DownloadTimePeriod
End Property
Public Property Let TimePeriod(ByVal Value As DownloadTimePeriod)
End Property
oh...
now I'm even more confused!
What in the name of all that is Holy was I doing?????
 
2:52 PM
Freestyle coding?
 
dopestyle coding
 
@FreeMan yeah that's what I thought - to be fair, when I first used interfaces, I did the same thing myself
 
yeah, I don't need those non-IWebDownloader_... versions of the Get/Let do I...
 
Not really. Mat gave a case where you might use it to set defaults for creating new ones if you have a factory method
 
I made this modification by copying what I saw at the top of my module and moving on.
 
2:54 PM
I would argue for defaults as a constructor parameter rather than a property on the default instance, but I can see the design work either way.
 
Private Sub Class_Initialize()

  LogManager.Log TraceLevel, "ApptPlusWebDownloader.Class_Initalize"
  Set this.SiteValues = New Scripting.Dictionary
  Set CheckboxByID = PopulateCheckboxByID

End Sub
^ closest I've got to a factory, and I'm directly referencing this.
gonna chuck those unnecessary ones in the bin and make my life easier.
 
so yeah, no. No point in exposing anything else. You do want to force all access via the interface to avoid accidental use of default instance or whatever
 
comments huge block of code. Presses Ctrl-D,C. Ducks awaiting massive explosion
yeah... all those "unnecessary" Get/Lets were the ones I was referencing. Now I need to go add IWebDownloader_ to the beginning of all those now failing to compile call sites.
:/
at least it'll be right now...
wait... this is my factory right here, isn't it?
Public Function Create(ByVal BrowserType As Browser, ByVal WhichSite As DownloadDataType) As IWebDownloader

  On Error GoTo ErrorHandler

  LogManager.Log DebugLevel, "ApptPlusWebDownloader.Create  Browser: " & BrowserType & "   Site: " & WhichSite

  With New ApptPlusWebDownloader
    .CallingLocation = "ApptPlusWebDownloader"
    .Browser = BrowserType
    Select Case .Browser
      Case Chrome
This is what needs the internal ones, because now that I've commented out Public Property Let CallingLocation(), that fails to compile
but, I could change Public Property to Private Property and everything will work and be kopasetic, right?
 
I don't think so.
I wonder if it's simpler to just expose a property that is same type as the this UDT
and set that, then pass back the instance (cast'd to interface, which will then hide that property)
but I think that might fail, too since the this UDT is supposed to be private
TBH, that's one of the biggest pain about encapsulating a factory method.
 
@FreeMan the GridCoord class (/IGridCoord interface) in the battleship project makes a good, simple example
 
3:09 PM
Yeah in that case you're mirroring the property in both the class and the interface.
 
@MathieuGuindon thanks
 
In this case, we only have 2 parameters, which is easy enough. If they need 10... it gets ugly
 
any class with 10 ctor arguments gets ugly
 
Just needs a "Danger Will Robinson"
 
it might not be 10 ctor arguments, though - some might be simply calculated from some other.
 
3:13 PM
 
But yes, agree that if a class needs more than 4 ctor parameters, then it might be doing too much.
We definitely don't see that in RD's codebase, right?
 
@this cough nope, none whatsoever cough cough
 
:D
drink some more water.
 
*coffee
 
*water
Haven't you heard how the make coffee?
They collect sewage from the treatment plant and dehydrate it.
It's a never-ending cycle. Goes in one end, comes out the other, and goes right back in.
/jk
 
3:18 PM
This is what happens when one drinks enough coffee:
though, some has been reported to turn into this instead:
#ChooseYourPoison
 
so really, I do need this:
27 mins ago, by FreeMan
user image
in my concrete implementations
 
If you want to set them as part of construction via the factory, yeah
 
based on looking at IGridCoord and GridCoord
with 'em there, code all compiles. and that's a plus in my book! :)
 
@this Why "burdening you with choices you shouldn't have to make" instead of "flexible, with a default option that will work for some people but not everyone"? Not doubting what you are saying, I just don't understand yet how you reached your conclusion.
 
confusion on the CE between my Access project and Battleship: In my project, I see:
When I click the arrow next to the Interface, it expands and shows me the elements. However, in Battleship, I click the arrow next to the Interface and I get:
 
3:29 PM
@puzzlepiece87 that link listed 3 different approaches to do essentially the same thing: start an WPF application. Only one is really enough. I can kind of see arguments for the XAML-only approach as an alternative for where you don't need customization, but given that all ultimately boils down to a variant of the Main with different effects is just needlessly complicating things.
 
a different shaped arrow, but it doesn't expand to show me methods/properties. What's the difference? Is it Excel v Access (wouldn't think so...)?
 
huh
it should expand to show the IGridCoord members
looks like a CE glitch
 
Found a bug. Go me!
@MathieuGuindon you have something else in Excel with an interface to give it a quick test? I do not...
 
@this That sounds both true but maybe also a natural consequence of WPF being used for sooo many things: console apps, desktop apps, browser apps, etc. It's difficult to make something so powerful without allowing customization in ways that can sometimes lead to what you mentioned above. But you're still correct in a perfect world, probably.
 
Having choices is fine. Having choices that aren't really necessary isn't fine. Knowing when it's really necessary is the hard part.
and from what I've seen, systems that has less choices work better generally than systems that can do anything but leaves up to you to do all the plumbing.
 
3:40 PM
#NoRepro
 
> **Rubberduck version information**
Version 2.4.1.4848
OS: Microsoft Windows NT 10.0.15063.0, x64
Host Product: Microsoft Office 2016 x64
Host Version: 16.0.4873.1000
Host Executable: MSACCESS.EXE
_and_
Host Executable: EXCEL.EXE

**Description**
In Access, when I click on the "expand" arrow of an `Interface` in the Code Explorer it expands to show me the members. In Excel, it does _not_

**To Reproduce**
Steps to reproduce the behavior:
1. Create an Interface, parse the code
2.
 
#ReportedAnyway
Maybe there's something in the log to show where it borked on my machine.
 
have you tried reparsing?
 
several times
 
#5094 has high odds of turning into
 
3:45 PM
> Despite having parsed several times, this persisted in Excel. Closing Excel & reopening causes the issue to go away.

Maybe there's something in the logs for posterity to ponder, but... #NoRepo
 
you'll have to tag it, but I closed it... :/
Excel crashed both times I closed it with Battleship.xlsm open. That's always fun!
 
#DistractionsIDidntNeedToday
 
that version has freeze panes on the gamesheet and titlesheet, right?
I really need to update the battleship repo...
 
think so. I also didn't (for some reason) have macros enabled for that file or network share...
 
3:48 PM
you put battleship on a network share? :D
in other news, today might be the day I hit 50K on SO
 
hmm not sure CE will work if macro is disabled?
it might cause the project to be locked
which may in turn affect how we can see the results
Not sure that's an explanation, though. I'd think that if it was private, it wouldn't be visible and I don't think the property are friends.
 
@MathieuGuindon how else is everyone else gonna play it?
 
but the expand arrow surely means the CE knows there's something to display there... something is wrong
@FreeMan lol
 
yeah that is true.
still doesn't mean it's a bug that only manifests when it's locked
I would hope that the fact that it's on a network share wouldn't make any difference (!). But I can see how a locked project might cause differences in the behavior because I know we have different code paths for locked projects.
 
@this :+1:
 
3:55 PM
Yup! having macros disabled on the file causes it to fail to expand.
that's a fun one!
 
> If macros are disabled in the Excel project, the CE will fail to expand the Interface tree view. If, however, macros are enabled, it will expand just fine.
 
ping... pong... ping... pong...
 
Yeah something's wrong there. the lockness of project shouldn't have bearing on that particular aspect. Either you see it or you don't.
 
presumably getting the members off ITypeInfo would fix that? ...doesn't make sense indeed.
 
3:59 PM
Maybe but I think that since we ahve the expand arrow we know there's members already
 
Yeah
Thinking the logs must have an exception somewhere...
 
4:35 PM
The inconsistency and inanity of our code reaches astounding levels.
First and Single are banned because they can throw exceptions.
But it isn't required to check for null if you don't use them.
 
uh what?
 
I'd rather have a First throw because there is no item than a null crash.
 
I see First or Single as a convenient way to Debug.Assert.
^^
 
Because the FirstOrDefault...
IKR?
And it even gives you a sensible error message that reduces fix time...
 
I'm not sure where you're getting the First and Single are banned from?
 
4:37 PM
From our architects...
 
ohhh... you mean at work?
 
~sigh
sometimes.
 
I think I'd better not say what I was just about to say.
Since this is a public room and all :P
 
well, if there can be one or none, SingleOrDefault is the only sensible approach... wtf?
oh wait, if there are none, let's use exceptions for flow control!
#SomeArchitect
 
4:39 PM
You described our system.
We throw and catch exceptions all the time, instead of using error flags.
 
@MathieuGuindon meh. if there is an expectation for "one or none", you actually want a Maybe instead of using SingleOrDefault
it's just that C# doesn't have a proper Maybe, much less integration for it in LINQ
and writing a correct wrapper is possibly nontrivial
then again MaybeFirst and MaybeSingle should be useful
 
not sure what Maybe does that SingleOrDefault doesn't?
SingleOrDefault throws if it's not single item
 
@this it encapsulates the expectation without using null
so you get something you can call methods on without risking an NPE
 
@IvenBach You're supposed to RTFM github.com/nunit/docs/wiki/Visual-Studio-Test-Adapter. Doing so lead you to marketplace.visualstudio.com/… which got the tests running.
@23fc9a62-56de-47fb-97b4-737890 :offers-condolences:
 
@Vogel612 hmm I still don't follow. So I get back IFoo that's... not null?
but it's an exception?
 
4:47 PM
no. it's a Maybe.EMPTY
 
@IvenBach You heard from the recruiter yet?
 
basically a library implementation of the null-object pattern
 
I'll give him another ping.
 
and if I call IFoo.Bar(), then what happens? Nothing still?
This feels weird.
 
@MathieuGuindon FYI- the log there may be some weird combination of Excel and Access parsing - not really sure how that works where there are 2 hose VBEs open.
 
4:47 PM
Maybe I'm not understanding
 
depends on the implementation
 
are we talking about an equivalent of null object pattern?
 
@this Nothing happens, and you get a Maybe<T> back.
It's basically like a Nullable<T>.
 
except nullsafe
 
Except you actually get an instance of the expected object back.
And in most languages, it kind of forces you to check both paths.
 
4:48 PM
TBH, that feels weird
 
@23fc9a62-56de-47fb-97b4-737890 No. I've had a slight uptick on LI views but no contact. Again using free time to work through my unit testing book. Finally understood [TestCase("FooBar")] attribute.
 
that's just more values of "null"s to check.
 
no.
because there is no null
 
but it's an empty husk?
which is .... same.
 
Except you often can't usually do item.Value either.
You do something like a pattern match.
Which is basically like if (item is Value v) ... else ...
And if it doesn't have a value, you hit the else.
 
4:52 PM
@this consider something like the following functional code:
 
It really doesn't work as well in OOP, since you can't check things as tightly.
Like, in functional programming, you kind of have to have an else on every if.
Because it enforces that the last, and only the last, statement is the return value in most of the languages.
 
fun findBy(predicate : a -> Bool, mapper : a -> b) : Maybe<b>
  return collection
    .where(predicate)
    .first()
    .map(mapper)
 
does it terminate early when first() fails to return something?
 
sigh
I just saw the mess happening in the 2nd.
@this No, it returns an object.
Just an empty "default" object.
It's maps responsibility to determine how to map it.
first is always guaranteed to return something.
 
the cool part there is that the mapper doesn't need to worry about the thing being a Maybe<a>
 
5:06 PM
Ok in my mind if first() has no match, it should just short-circuit. What's the point of continuing?
 
@this because the types are not matching yet. first returns a Maybe<a>
 
You don't short circuit either way.
 
that, too..
 
In C#, you get the result and then test the result and branch there.
In this, you leave the branch to the map implementation.
 
aha I missed that critical link.
 
5:07 PM
or rather: you leave the branching to the compiler
 
first() is returning Maybe<a> but we want Maybe<b> out of the whole thing, which comes from map
 
IOW avoid FirstOrDefault by turning First into something that may or may not return what we're after.
not sure it's a net gain
 
You just have to change your assumption of what you are after.
 
I can see why it'd be desirable in FP since as noted earlier compiler handles the branching; you just declare the expression without the procedural steps.
Would it be useful in C# or OOP? IDK.....
 
We'll find out in C# 8 with the nullable reference types.
 
5:14 PM
I think that's a different solution for a different problem.
 
@23fc9a62-56de-47fb-97b4-737890 ugh
 
Yeah, I don't care much for that user. They don't learn anything from reviews they get.
 
@this that
@FreeMan oh crap, that does complicate things..
 
@this It's basically the same thing, though.
You use a Maybe when you don't know.
Otherwise, you use the actual type.
 
@MathieuGuindon IIRC we have a open issue somewhere about creating separate log stream for different host instances....
 
5:17 PM
Like, inputs come with a maybe. Once you know you have something, you don't need the Maybe anymore.
 
in that case, it's back to using null vs. null-but-not-really-null
which feels like a lateral move.
or possibly a step back because you now have more "null" types to check for.
See: Variant's Empty and Null
 
I can see Maybe<b> makes sense in a language that doesn't have nullable types. But introducing it in C# feels pointless as long as object references are nullable and there's a Nullable<T> to box up value types.
or, I'm missing something - again
 
^
 
iiuc nullable types will be opt-in and (by default) generate compiler warnings - but neither of those are a big problem.
 
ok I don't understand wth the OP is trying to achieve here
I've had no problems with getting the class to enumerate 1 collection, but for the functionality I'm looking for, I wanted to enumerate 2. If I understand your answer correctly this is not something that can be done and I will need to find another solution for my second collection, perhaps an array. (I've also updated my question with more information) — Glenn G 1 hour ago
 
5:31 PM
Opt-out for new ones.
@mansellan Opt-in for existing projects.
 
@MathieuGuindon Commented. He is doing it wrong.
 
in so many ways, starting with the "cls" prefix
 
6:20 PM
Hm, we still don't handle newlines/line-breaks in docstrings, right?
 
sorry in what context?
 
@MathieuGuindon happy to help. ;)
 
e.g. Tim Hall's Dictionary class, has \n in the docstring
I think we should honor them in the code explorer, and replace them with a space in the rd toolbar (or only display the first line)
 
yeah CE should show same what we'd have seen in OB
 
was reminded with this slightly nonsensical thread:
0
Q: Using a vba-constant in Constant declaration

L8nSo, I'm trying to declare a Const that holds a description for my class, the description will have a few line-breaks/new-lines (just a new paragraph) in it. The value of which will later be returned trough a Property Get Method. I'm aware that you can't use function calls like Chr(10) (which is...

 
00:00 - 19:0019:00 - 00:00

« first day (1901 days earlier)      last day (33 days later) »