Shell.Application
was added for WScript and CScript scripts, so the actual functionality should be accessible directly with Win32::API. I'm not sure at the moment what it is calling under the hood.]]>
Win32::IsAdminUser()
to check for elevated privileges? The docs say:
Returns non zero if the account in whose security context the current process/thread is running belongs to the local group of Administrators in the built-in system domain; returns 0 if not. On Windows Vista it will only return non-zero if the process is actually running with elevated privileges. Returns undef and prints a warning if an error occurred. This function always returns 1 on Win9X.
]]>Thanks!
]]>Lots of Perl-related tools live in the Perl:: namespace, like Perl::Tidy, Perl::Critic, Perl::PrereqScanner. So Perl::IDE:: would be an entirely appropriate namespace, I think.
]]>Nice talk as always.
It seems you can read my mind. I have been going through this question for sometimes.
Keep up the good work.
Mohammad S Anwar
]]>I truly hate "branded", non-descriptive names. It gives me the impression that the author was lazy or a trying to be a hipster, and lowers my expectations on the quality of their contribution.
]]>
BTW See the naming section of Starman.
Maybe Role::Attr::CachedURL
Though looking at what you have, a few things may be true:
A) The role may not be applicable if you aren't using Moo and thus won't work with "Role::Tiny::With
", mostly because of that requirement you use Moo to set the URL.
B) The current interface seems limited in that it can only compose in one attribute, where multiple may be desirable.
B is currently YAGNI territory.
Hm, looking at existing things, it may even be better to write what you currently have if you don't plan on going beyond and allowing B, to call it:
MooX::Role::HasURL::Cached
"HasURL
" is much more clear that it associates a 1:1 mapping that is not very flexible.
But IMO, if you want to get the "MooX" part out of the name, then you need to have an interface that doesn't require the user to use Moo; ... has +url =>
Say:
use Role::HasURL::Cached { url => 'myurl' };
However, if you were to write the logic in terms of Package::Variant
or similar, you could do:
use Role::URL::Cached {
url_google => 'http://google.com/',
url_metacpan => ....,
};
But I don't see you easily unbriding it from making the user use Moo/Moose.
Even those import
style tricks I've used, while nice, are prone to confuse users who expect to do:
with Role
not use Role
blogs.perl.org, after allowing me to review my comment with preview multiple times, spontaneously decided to tell me my session had expired and summarily discarded all my effort when I finally went to submit it.
It is only by the grace of perseverance and TextAreaCache that I was able to retrieve my comment from browser memory, go back to the blog page, and submit it fresh with no preview process.
I find it hard to communicate just how horrific I find blogs.perl.org, both as a person commenting, and a person using it as a blogging platform.
]]>Searching the Internet has long ago moved away from guessing domain names, and we now rely on search engines that analyze content and, in particular, use links to bubble interesting content.
SEO science now relies on links between content. That's why linking related modules from POD is more important than ever, so fill your own SEE ALSO section and send patches to others SEE ALSO for them to link to your code.
Write blog posts about it, tweet it...
The workaround is to preview, then hit back, (if necessary, edit it some more, preview again, and go back again... until you are satisfied with your comment), and then post the comment. You need to post it from the first comment form you started using, not from the preview pages.
]]>