Raised This Month: $12 Target: $400
 3% 

Syntax Update: Removals


Post New Thread Reply   
 
Thread Tools Display Modes
Author Message
BAILOPAN
Join Date: Jan 2004
Old 08-11-2015 , 23:33   Syntax Update: Removals
Reply With Quote #1

Hi All,

After letting the new syntax make its rounds, there are a few adjustments I'd like to make. Nothing new in this post, only removals (sorry!)

Intrinsic Handle

Handle will no longer have a methodmap in handles.inc. It will be a compiler intrinsic. You will still be able to delete and Close() it (although Clone has been removed as a method).

Removing Destructors

These were intended for extensions, but they were difficult to support in the language without exposing terrible things (like, potentially, object resurrection if we ever do GC). Instead, destructors will go away entirely. You can still use delete on Handles because they're now intrinsic.

Neutering __nullable__

For such an important piece of future type system sanity, this one was a pretty bad leak. It was undocumented but that didn't stop people from creating alternate nullable systems that violated its intended semantics. __nullable__ will still allow using new with custom constructors, but it won't allow comparing to null.

Removing () = binding

When we were first prototyping methodmaps, we added a shortcut method declaration syntax, called "method binding". It looks like this: NewMethod () = OldMethod. This syntax is incredibly annoying to support in the compiler, and our docgen tools don't support it at all. Our own usage of it is almost gone in the 1.7 branch.

So, I will attempt to just remove it entirely in 1.8. There are three ways to fix up your methodmaps. One is to just write wrapper functions that call the old function. Two is to just delete the old function and move any lingering code into methodmap-land. Finally, if you are an extension, you can create another native binding. For example,

PHP Code:
// C++...
   
"CreateRegex"CreateRegex },

// Pawn
native CreateRegex();
methodmap Regex {
  public 
native Regex() = CreateRegex
You can instead do:

PHP Code:
// C++...
   
"CreateRegex"CreateRegex },
   { 
"Regex.Regex"CreateRegex },

// Pawn
methodmap Regex {
  public 
native Regex(); 

(This change will definitely not be backported to 1.7.)

Requiring parens on view_as<>

A mistake in the implementation of view_as<> allowed using it without parenthesizing the affected expression. This has been fixed already on 1.8.
__________________
egg

Last edited by BAILOPAN; 08-12-2015 at 00:42.
BAILOPAN is offline
WildCard65
Veteran Member
Join Date: Aug 2013
Location: Canada
Old 08-12-2015 , 07:14   Re: Syntax Update: Removals
Reply With Quote #2

I was wondering y DataPack and Handle methodmaps were the only 2 methodmaps I found in 1.7 that did the method binding while all others didn't
__________________
WildCard65 is offline
BAILOPAN
Join Date: Jan 2004
Old 08-12-2015 , 14:11   Re: Syntax Update: Removals
Reply With Quote #3

The answer is we were lazy.
__________________
egg
BAILOPAN is offline
WildCard65
Veteran Member
Join Date: Aug 2013
Location: Canada
Old 08-12-2015 , 15:12   Re: Syntax Update: Removals
Reply With Quote #4

Quote:
Originally Posted by BAILOPAN View Post
The answer is we were lazy.
I was under the impression that you just forgot about them.
__________________
WildCard65 is offline
KissLick
Veteran Member
Join Date: Nov 2012
Location: void
Old 08-12-2015 , 15:48   Re: Syntax Update: Removals
Reply With Quote #5

Quote:
Originally Posted by BAILOPAN View Post
The answer is we were lazy.
Now you have destroyed illusions of many devoted SM scripters :-D :-D
KissLick is offline
Potato Uno
Veteran Member
Join Date: Jan 2014
Location: Atlanta, Georgia
Old 08-12-2015 , 16:57   Re: Syntax Update: Removals
Reply With Quote #6

Quote:
Originally Posted by BAILOPAN
This message has been deleted by BAILOPAN. Reason: First delete
LOL. <3 SM devs.

Also shit, does that mean I should expect my plugins with #pragma newdecls required to not compile under 1.8? Should I expect possibly more things to be gone from 1.7?

I'm guilty of not using parentheses under view_as<type>.

Last edited by Potato Uno; 08-12-2015 at 17:00.
Potato Uno is offline
BAILOPAN
Join Date: Jan 2004
Old 08-12-2015 , 17:27   Re: Syntax Update: Removals
Reply With Quote #7

Anything requiring newdecls should continue to work. Only what has been noted above is changing.
__________________
egg
BAILOPAN is offline
databomb
Veteran Member
Join Date: Jun 2009
Location: california
Old 08-22-2015 , 00:14   Re: Syntax Update: Removals
Reply With Quote #8

Quote:
Originally Posted by BAILOPAN View Post
Neutering __nullable__

For such an important piece of future type system sanity, this one was a pretty bad leak. It was undocumented but that didn't stop people from creating alternate nullable systems that violated its intended semantics. __nullable__ will still allow using new with custom constructors, but it won't allow comparing to null.
How would this change the syntax of the constructors in an example like https://github.com/VoiDeD/sourcemod-...tional-helpers ? There might be some lingering violations of a null comparison in entity.inc but keeping __nullable__ on the CBaseEntity methodmap seems to prevent an instantiation of a child object like
CBasePlayer player = new CBasePlayer( client );

edit: in case this is a bug and not just another syntactic miss on my part,

if I modify https://github.com/alliedmodders/sou...e-methodmap.sp to

PHP Code:
native void printnum(int num);

methodmap Crab __nullable__
{
    public 
Crab() {
        return 
view_as<Crab>(2);
    }
};

methodmap King Crab
{
    public 
King() {
        return 
view_as<King>(new Crab());
    }
};

methodmap Layer3 King
{
    public 
Layer3() {
        return 
view_as<Layer3>(new King());
    }
}

public 
main()
{
    
Crab egg = new Crab();
    
printnum(_:egg);
    
    
King baby = new King();
    
printnum(_:baby);
    
    
Layer3 stuff = new Layer3();
    
printnum(_:stuff);

it produces:
//// test-nullable.sp
//
// test-nullable.sp(29) : error 171: cannot use 'new' with non-object-like methodmap 'King'
// test-nullable.sp(29) : warning 213: tag mismatch
// test-nullable.sp(32) : error 171: cannot use 'new' with non-object-like methodmap 'Layer3'
// test-nullable.sp(32) : warning 213: tag mismatch
//
__________________

Last edited by databomb; 08-22-2015 at 12:11.
databomb is offline
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 19:38.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Theme made by Freecode